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POLICY: Pascal News (78/04/15) 

* Pascal News is the official but informal publication of the User's Group, 

Pascal News contains all we (the editors) know about Pascal; we use it as 
the vehicle to answer all inquiries because our physical energy and 
resources for answering individual requests are finite. As PUG grows, we 
unfortunately succumb to the reality of (1) having to insist that people 
who need to know "about Pascal" join PUG and read Pascal News ■ that is 
why we spend time to produce it! and (2) refusing to return phone calls 
or answer letters full of questions - we will pass the questions on to 
the readership of Pascal News . Please understand what the collective 
effect of individual inquiries has at the "concentrators" (our phones and 
mailboxes). We are trying honestly to say: "we cannot promise more than 
we can do." 

* An attempt is made to produce Pascal News 3 or 4 times during an academic year 

from July 1 to June 30; usually September, November, February, and May. 

* ALL THE NEWS THAT FITS, WE PRINT. Please send material (brevity is a virtue) for 

Pascal News single-spaced and camera-ready (use dark ribbon and 18.5 cm lines!). 

* Remember: ALL LETTERS TO US WILL BE PRINTED UNLESS THEY CONTAIN A REQUEST TO 

THE CONTRARY. 

* Pascal News is divided into flexible sections: 

POLICY - tries to explain the way we do things (ALL PURPOSE COUPON, etc.). 

EDITOR'S CONTRIBUTION - passes along the opinion and point of view of the 
editor together with changes in the mechanics of PUG operation, etc. 

HERE AND THERE WITH PASCAL - presents news from people, conference 
announcements and reports, new books and articles (including reviews), 
notices of Pascal in the news, history, membership rosters, etc. 

APPLICATIONS - presents and documents source programs written in Pascal for 
various algorithms, and software tools for a Pascal environment; news of 
significant applications programs. Also critiques regarding program/algorithm 
certification, performance, standards conformance, style, output convenience, 
and general design. 

ARTICLES - contains formal, submitted contributions (such as Pascal 
philosophy, use of Pascal as a teaching tool, use of Pascal at different 
computer installations, how to promote Pascal, etc.) 

OPEN FORUM FOR MEMBERS - contains short, informal correspondence among 
members which is of interest to the readership of Pascal News . 

IMPLEMENTATION NOTES - reports news of Pascal implementations: contacts 
for maintainers, implementors, distributors, and documentors of various 
implementations as well as where to send bug reports. Qualitative and 
quantitative descriptions and comparisons of various implementations are 
publicized. Sections contain information about Portable Pascals, Pascal 
Variants, Feature Implementation Notes, and Machine Dependent Implementati( 

* Volunteer editors are (addresses in the respective sections of Pascal News ) : 

Andy Mickel - editor 

Jim Miner and Tim Bonham - Implementation Notes editors 

Sara Graffunder - Here and There editor 

Rich Stevens - Books and Articles editor 

Rich Cichelli - Applications editor 

Tony Addyman - Standards editor 

Scott Bertilson, John Easton, and Steve Riesman - Tasks editors 



PASCAL USER'S GROUP 

USER'S ALL PURPOSE COUPON 

GROU? 

(78/04/15) • 

Pascal User's Group, c/o Andy Mickel ^ CLcp, photocopy, on. 

University Computer Center: 227 EX -^ 

208 SE Union Street ^ mpModucc, etc. and 

University of Minnesota -<- 

Minneapolis, MN 55455 USA <- mall to thJj> addxu^b. 

I I Please enter me as a new member of the PASCAL USER'S GROUP for Academic 

year(s) ending June 30, (not past 1982), I shall receive all the 

issues of Va^dot ^fex^^ for each year. Enclosed please find . (* Please 

see the POLICY section on the reverse side for prices and if you are joining 
from overseas, check for a PUG "regional representative," *) 

/ / Please renew my membership in PASCAL USER'S GROUP for Academic year(s) 

ending June 30, (not past 1982). Enclosed please find . 

/ / Please send a copy of Vaj^doJi hlm6 Number(s) . (* See the Pa^cat hl2w^ 

POLICY section on the reverse side for prices and issues available. *) 

/ / My new ^^^^^ is printed below. Please use it from now on. I'll enclose an 
old mailing label if I can find one. 

/ / You messed up my ^u^ry^.^ • See below. 

/ / Enclosed please find a contribution (such as what we are doing with Pascal at 
our computer installation), idea, article, or opinion which I wish to submit 
for publication in the next issue of Pascal Nm^ . (* Please send bug reports 
to the maintainer of the appropriate implementation listed in the Pascal hlm^ 
IMPLEMENTATION NOTES section. *) 

/ / None of the above. 



Other comments: From: name 

mailing address 



phone 

computer system(s) 

date 



(* Your Dhone number aids communication with other PUG members. *) 
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JOINING PASCAL USER'S GROUP? 

- membership is open to anyone: particularly the Pascal user, teacher, maintainer, 
implementor, distributor, or just plain fan. 

- please enclose the proper prepayment (checks payable to "Pascal User's Group"); 
we will not bill you. 

- please do not send us purchase orders; we cannot endure the paper work! (If you are 
trying to get your organization to pay for your membership, think of the cost of 
paperwork involved for such a small sum as a PUG membership!) 

- when you join PUG anytime within an academic year: July 1 to June 30, you will 
receive all issues of Pascal News for that year unless you request otherwise. 

- please remember that PUG is run by volunteers who don't consider themselves in the 
"publishing business." We produce Pascal News as a means toward the end of 
promoting Pascal and communicating news of events surrounding Pascal to persons 
interested in Pascal. We are simply interested in the news ourselves and prefer to 
share it through Pascal News , rather than having to answer individually every letter 
and phone call. We desire to minimize paperwork, because we have other work to do. 

- American Region (North and South America): Join through PUG(USA). Send $6.00 per year 
to the address on the reverse side. International telephone: 1-612-376-7290. 

- European Region (Europe, North Africa, Western and Central Asia): Join through PUG(UK). 
Send ^4.00 per year to: Pascal Users' Group/ c/o Computer Studies Group/ Mathematics 
Department/ The University/ Southampton S09 5NH/ United Kingdom . International 
telephone: 44-703-559122 x700. 

_ - Australasian Region (Australia, East Asia -incl. Japan): Join through PUG(AUS). 

o Send $A8.00 per year to: Pascal Users Group/ c/o Arthur Sale/ Dept. of Information 

Science/ University of Tasmania/ Box 252C GPO/ Hobart, Tasmania 7001/ Australia . 

International Telephone: 61-02-23 0561. 

PUG(USA) produces Pascal News and keeps all mailing addresses on a common list. 

Regional representatives collect memberships from their regions as a service, and 
they reprint and distribute Pascal News using a proof copy and mailing labels sent 
from PUG(USA). Persons in the Australasian and European Regions must join through 
their regional representatives. People in other places can join through PUG(USA). 

RENEWING? (Costs the same as joining.) 

- please renew early (before August) and please write us a line or two to tell us what 
you are doing with Pascal, and tell us what you think of PUG and Pascal News to help 
keep us honest. Renewing for more than one year saves us time. 

ORDERING BACKISSUES OR EXTRA ISSUES? 

- our unusual policy of automatically sending all issues of Pascal News to anyone who 
joins within an academic year (July 1 to June 30) means that we eliminate many 
requests for backissues ahead of time, and we don*t have to reprint important 
information in eyery issue--especially about Pascal implementations! 

- Issues 1, 2, 3, and 4 (January, 1974 - August, 1976) are out of print . 

- Issues 5, 6, 7, and 8 (September, 1976 - May, 1977) are out of print . 
(A few copies of issue 8 remain at PUG(UK) available foriE:2 each.) 

- Issues 9, 10, 11, and 12 (September, 1977 - June, 1978) are available from PUG(USA) 
all for $10 and from PUG(AUS) all for $A10. 

- extra single copies of new issues (current academic year) are: 
$3 each - PUG(USA); -£2 each - PUG(UK); and $A3 each - PUG(AUS). 

SENDING MATERIAL FOR PUBLICATION? 

- check the addresses for specific editors in Pascal News . Your experiences with Pascal 
(teaching and otherwise), ideas, letters, opinions, notices, news, articles, 
conference announcements, reports, implementation information, applications, etc. 
are welcome. "All The News That Fits, We Print." Please send material single-spaced 
and in camera-ready (use a dark ribbon and lines 18.5 cm wide) form. 

- remember: All letters to us will be printed unless they contain a request to the 
contrary. 

MISCELLANEOUS INQUIRIES? . . 

- Please remember that we will use Pascal News as the medium to answer all inquiries, and 
we regret to be unable to answer individual requests. 
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UNIVERSITY OF MINNESOTA 

TWIN CITIES 



University Computer Center 

227 Experimental Engineering Building 

IVIinneapolis, Minnesota 55455 

(612) 376-7290 



The DEADLINE for PUGN 13/14 is August 15. Tony Addyman is now PUG's new Standards 
Editor. Don't forget to renew if you need to— check your mailing label. 

Personal Observations 

T) Pascal -P has enabled a great many people to learn about compilers who otherwise 
would never have had the chance. Do you realize the implications? These same people 
(myself included) will never be able to look at other compilers for other languages 
(especially the ones peddled by manufacturers) the same way from now on. Our critical 
eyes probably won't be able to endure them either. 

2) Please see the Books and Articles section for the article entitled: "Ambiguities and 
Insecurities in Pascal," which is the first, good, critical article about Pascal to 
appear (yes, we know about Habermann's article). The most memorable passage is in the 
conclusion: 

"...Because of the wery success of Pascal, which greatly exceeded the 
expectations of its author, the standards by which we judge such languages 
have also risen. It is grossly unfair to judge an engineering project 
by standards which have been proved attainable only by the success of the 
project itself, but in the interests of progress, such criticism must be made." 

3) Many people are now decrying the lack in Pascal of "business-oriented" language 
features such as indexed-sequential access methods for file processing, packed decimal 
data types, and other inefficient ways of doing computing. I would suggest a Business 
Procedure Library similar to the IMSL and NAG mathematical and statistics libraries 

for numerical (old term = 'scientific') people. We should use the simple, but versatile 
tools (language features) we already have to build what we need for other things. 

4) We need more news (notices, articles, opinions, etc.) for Pascal News about teaching 
experiences with Pascal. 

How is Pascal User's Group? (*new members especially please read this*) 
PUG has now grown too large to handle it in the personal manner we have in the past. 
Membership stands at 2147+. We used to be extremely efficient, because I, for one, 
could keep it all in my head and remember who was a member from where, which joined when 
and how. It was like stamp collecting. We have resorted to dropping all kinds of services 
we never promised to do but nevertheless did. Now when a new member joins, all he or she 
receives is backissues, and no personal reply, receipt, or answers to questions. PUG 
is another example illustrating limits to growth . 

The event that seems to have changed the situation permanently was the first full -page 
article about Pascal in the April 27 issue of Computerworld— the largest and most widely- 
read computer journal in the United States. The following Monday we received 83 pieces 
of mail in one day (old record for a single day was 39 pieces, while typical mail in the 
past averaged 20-30 pieces/week.)! Do you realize how much time it takes to open 83 
pieces of mail? Remember, we don't have secretaries. 

PUG(USA) has managed to break even in the past--including this year--but we must raise the 
rates to $6 per year. Postage and printing costs keep rising. David Barron at PUG(UK) 
announces new rates of 4 per year and Arthur Sale at PUG(AUS) announces a $A2 decrease 
(now $A8). Please see their notices following. At least now our rates are more 
normalized. We have kept the rate low to attract members and to spread Pascal as fast and 
as far as possible. We as a group are an exceptionally broad base of people, and I think 
that is a real accomplishment. And remember, we accept no advertizing. 

We have always tried to keep this operation simple: no special services, no special rates 
for special mailing, etc. I know I just wouldn't have time otherwise. I set up PUG 
so that it can be dismantled within one week and all money refunded! Charging a little 
more money this year will allow us to hire a part-time secretary to handle the growing 
clerical workload. The most time-consuming process is to process memberships and update 
the mailing list. We usually batch 3 or 4 weeks of mail before we process it! 



Editor's Contribution 
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Dear Andy, 

Here is our cost estimates for Australasian distribution for 1978/9. As you 
will see, I am recommending a lowering of the fee to $A8.00. Last year's fee was 
based on estimates from our printery which in the even proved slightly high, and 
of course the amalgamation of issues 9 and 10 saved us postage. Consequently we 
have a small reserve, and I have been able to budget for exactly balancing costs 
with subs in 1978/79, carrying any inflation in postage and the costs of carrying 
stocks of back copies out of the reserve. 

There may be some request for refunds from people who paid for two years. 
I'd rather not be involved in sending out cheques, and I suggest we treat this the 
same as with people who pay for two years in a price rise situation: we don't ask 
for more so we shouldn't give refunds. 
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Printing cost per issue 

Postage : Australia $0.70 
New Zealand $1.20 
Singapore $2.00 
averaged over subscribers 



$1.00 



$1.00 approx. 



Cost per issue $2.00 

Recommended subscription for 1978/79 = $8.00 (Australian) 



Yours sincerely. 



JA/ 



A.H.J. Sale, 

Department of Information Science . 
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PASCAL USERS GROUP - European Region Subscriptions 1978/79 

We regret that steep increases in the cost of 
printing compel us to increase the subscription 
to £4 PER ANNUM . 

We regret the increase, but even at this figure 
we shall only just break even. Without volunteer 
labour, charges would be much higher. 

Please remember that cheques must be in sterling , 
drawn on a British (or Irish) bank Processing 
sterling cheques drawn on foreign banks, or non- 
sterling cheques is prohibitively expensive. 

If you have a Post-Giro account, you can pay by 
direct transfer into our account number 28 513 4000. 

RENEWALS take time, which is precious. Why not 
subscribe for two or more years? 
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Here and There With Pascal 



the Pascal compiler 
(* 78/03/05 *) 



written in Pascal developed at SLAC, Stanford University. 



NEWS 



Pascal Jobs 

(* PUG Member Jack Laffe has been keeping track of some of the jobs for Pascalers which 
have been advertised in recent months. We decided to publish it as one more indication 
of the currency of Pascal. This is not a "Help Wanted" section; in fact, these jobs may 
have been filled. We may continue publishing this section, when space permits, if 
someone like Jack will compile the list. *) 

(* The first job was advertised in CACM in January. The others all appeared in Computer 
World on the date indicated with the job description. *) 

Softech: compiler design. 

Dunhill Personnel Inc.: 78/01/02 

Modular Computer Systems: 78/01/23 

National Cash Register: compiler design for Pascal-like language: 78/01/30 

Timeshare: applications, systems: 78/02/06 

Amdahl: systems programmer with Pascal experience: 78/02/27 

California State Universities and Colleges: instructional consultants in Pascal: 

78/03/06 
GTE Sylvania: software engineers: 78/03/20 
Houghton-Mifflin: Pascal programmers: 78/3 

Tidbits 

Richard E. Adams , 239 Chatham Road, Columbus, OH 43214: "Did you hear that Burroughs was 
implementing Pascal on a microprocessor? (They were advertising for people in 
Computerworld ." (* 78/02/09 *) 

Wayne Andrews , Electronics Department, Weber State College, 3750 Harrison Blvd., Ogden, 
UT 84408: "We just put Pascal on our Dec-10 system and are trying to get going on the 
project." (* 78/03/06 *) 

C. Bailey, Bailey and Associates, 1144 S. Atlanta, Tulsa, OK 74104: "I have an Altair 
with 32K memory, 2 Altair Floppy Discs and a Decwriter. So I am interested in Pascal as 
implemented on the Altair or Altair-like CPU. I am employed as a programmer/analyst for 
the Altair and HP and SG minis." (* 77/12/30 *) 

Francis H. Beardon , Manager of Projects, Data Systems, Cincinnati Electronics, 2630 
Glendale-Milford Road, Cincinnati, OH 45241: "We at Cincinnati Electronics Corporation 
are interested in Pascal as a possible standard programming language for our developed 
software systems because of its projected portability. 



(* 78/02/13 *) 



David J. Bell , 609 Craig Ave., Campbell, CA 95008: "My personal system is a Processor 
Tech SOL-10, with externally expanded memory and I/O. I am interested in developing a 
Pascal translator for this computer, and for the HP2112 I use at work." (* 78/03/10 *) 



Brad Biasing, 1308 Centennial Hall, Univ. Of MN, Minneapolis, MN 55455: "We have 
implemented the Netherlands Pascal compiler on our 11/40 running UNIX. Runs fast for an 
interpreter. It's a good hybrid of the P2 and P4 compiler. Could use a bit more 
user-type documentation." (* 78/04/02 *) 

William R. Blatchley , Measurement Systems Div., Siemans Corp., 3 Computer Drive, Cherry 
Hill, NJ 08002: "We are engaged in test equipment design and development for memory 
devices and have a possibly immediate need for a Pascal implementation on a PDP-11 for 
testing magnetic bubble memories." (* 78/04/12 *) 

Damon Blom, 72 Sandburg Drive, Sacramento, CA 95819: "I am presently using Pascal on an 
IBM 370/168 computer using a Pascal compiler written in XPL. I will be getting shortly 



Richard J. Ciche lli 
Villanova has 



901 Whittier Dr. 



Allentown, PA 



18103: "Joseph Mezzaroba at 

supervised two projects to implement Pascal-S on the 370. One using the 
AAEC Pascal compiler (Pascal-S in Pascal — takes 100 seconds to compile) and the IBM 
PL/1 compiler (Pascal-S in PL/1 — takes 36 minutes to compile). Pascal-S in Pascal was 
30 per cent smaller and ran five times faster." (* 78/04/14 *) 

Roger Creamer, CTB /McGraw-Hill, Del Monte Research Park, Monterey, CA 93940: "Also, any 
specific information which you could provide on Pascal implementations for the IBM 370 
and DEC PDP-11 would be much appreciated." (* 78/04/14 *) 

Anthony Conti, Box 1201, Concord, NH 03301: "I am a user of a Data General Eclipse S200 
minicomputer and am interested in running and maintaining Pascal on it." (* 78/01/12 *) 

Jean-Louis Decoster , Lyss-Str. 21, CH-2560 Nidau, Switzerland: "Could you inform me too 
if a Pascal compiler is already implemented for "Could you inform me too if a Pascal 
compiler is already implemented for the Motorola 6800?" (* 78/03/15 *) 

Alan Delwiche , Computer Programming Instructor, Leland High School, 6677 Camden Ave., 
San Jose, CA 95120: "Would you please send me any information regarding versions of 
Pascal for an 8080 or Z80 microprocessor. We have a 32K Cromemco with dual minifloppy 
drives." (* 78/02/08 *) 

Shaun Devlin , 6854 Cedarbrook, Birmingham, MI 48010: "I would also appreciate it if you 
could direct me to anyone who has or is planning to implement Pascal on a Texas 
Instrument 990/9900 system." (* 78/01/05 *) 

Bob Dietrich, M.S. 60-456, Tektronix, Inc., P.O. Box 500, Beaverton, OR 97077: "Am 
bringing up solo-concurrent Pascal under RSTS/E time sharing system (PDP-11). Also 
involved with Swedish and BSM Pascals for PDP-11." (* 78/03/08 *) 

Robert Emerson , Honeywell Information Systems, 9555 S.E. 36th St., Mercer Island, WA 
98040: "Another interest of mine is implementing a Pascal compiler on the Honeywell 
Level 6 mini computer. Any tips for compiler implementation would also be appreciated." 
(* 78/01/17 *) 

Mel R. Fisher , Business Dept., Calvary Community Church, 1175 Hillsdale Ave., San Jose, 
CA 95118: "I am in the process of writing specialized programs for our church records, 
bookkeeping, and data of this nature. The Pascal language sounds very interesting, and 
I would appreciate any further information that you could supply me with. We currently 
have an IMSAI 8080 48K memory, with floppy disk video display and printer." 
(* 78/02/15 *) 

George H. Golden , Sr. , Computer Center, SUNY-Fredonia, Fredonia, NY 14063: "We are 
trying to get Pascal running on the Burroughs B-4700. It runs. But takes too much 
core." (* 78/04/10 *) 

Robert M. Green, Robelle Consulting, Ltd., No. 130, 10th Ave., Delta, BC V4M 3T9: "Could 
you let me know if there are any implementations of Pascal for the Hewlett-Packard 3000 
computer? If not, I am interested in implementing it. Is there any way I can get a copy 
of the Portable Pascal compiler, version P4?" (* 78/02/02 *) 

R. Gunzenhauser and R. Kleine-Homann , Institut fur Informatik, Universitat Stuttgart, 7 
Stuttgart 1, Azenbergstr. 12, Germany: "We use Pascal as the first programming language 
for our freshman students and for high-school teachers. 

"We offer Pascal at our German Computer TR 440; besides we have a DEC PDP 11/40 
computer (OS DEC RSX 11-M, 92kBytes) and wish to implement Pascal or a Pascal subset 
like Pascal-S. 

"We would be very obliged if you could send us information about Pascal implementations 
on RSX 11-M you know." (* 78/03/15 *) 

Robert 0. Harris , University College London, Computer Center, 19 Gordon Street, London 
WCIA OAH, United Kingdom: "I read the bit on PUG finances and noticed that PUG (UK) 
were the big loss makers, so I reckon its time to stop reading the library copy and pay 
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for my own." (* ISlOUll *) 

Carroll Hennick , Autologic, Inc., 1050 Rancho Conejo 
"Your letter in SIGPC Notes was welcome." 



Blvd., Newbury Park, CA 91320: 



Judy Herron , Computer Sciences Dept., Mt. San Antonio College, 1100 North Grand Avenue, 
Walnut, CA 91789: "In my recent reading, references to Pascal seem to pop up 
everywhere — although I have yet to see one line of source code. 

"I'm interested in learning what I can about the language, and its implementations. 
What manufacturers offer Pascal? Is there a compiler available for our Altair 8800, 
Xerox 530, or IBM 1130? It sounds as though Pascal is used mainly for the teaching of 
structured programming techniques. Are business and industry adopting it also?" 
(* 77/12/28 *) 

Bruce Hillegass , Digital Equipment Corp., 146 Main St., Maynard, MA: "I obtained your 
name off a Pascal document located on one of our DEC Sys-lO's. 

"Pascal is virtually unsupported on all of our in-house systems, and there are numerous 
versions of the compiler around. I have been interested in Pascal for quite a while, 
and I'm in the process of learning the language. I am exploring the possibility of 
writing a compiler using Pascal as the language and I'm looking into Pascal as a 
language used in micro-programming. 

"I would appreciate any information you may have on Pascal activities in university 
environments especially on the DEC Sys-10." (* 78/01/27 *) 

Robert M. Hofkin , APIS Dept. C-014, Univ. Of CA-San Diego, La Jolla, CA 92093: "Language 
extensions seem necessary, but the syntax. Let's not have another PL/ll Also — why 
wasn't Cichelli's review of Ken Bowles' book critical? It sounded more like a product 
announcement from IBM." (* 78/03/17 *) 

David Holland , P.O. Box 38243, Houston, TX 77088: "in case you don't know already, T.I. 
Are getting ready for a Pascal compiler on a ROM for their 16-bit TMS9900 MP." 
(* 78/01/31 *) 

William F. Holmes , Washington University, School of Medicine, 660 South Euclid Ave., St. 
Louis, MO 63110: "We are not using Pascal at present, but are seriously considering it 
for the PDP-11 (including the LSI-11) and the 8080 or 6800. We also have Computer 
Automation's LSI-2's, but unfortunately do not use their operating system." 
(* 78/01/30 *) 



William C. Hopkins , 1101 Bondsville Rd. , Downingtown, PA 19335: 
a Univac 90/70 implementation." (* 78/02/26 *) 



still working on 



Gary M. Huckabay , Department of Mathematics, Cameron University, Lawton, OK 73505: "I 
would appreciate information concerning the following: i) language definition, ii) 
implementation at any computer site, iii) any suggestions on implementation, iv) any 
information concerning implementation on the Hewlett-Packard 3000, Series II." 
(* 78/01/26 *) 

Phil Hughes , P.O. Box 2847, Olympia, WA 98507: "I have been studying and debating 
whether to implement Pascal on a micro for over 6 months. The article 'Pascal vs. 
Basic' made me aw^re of two things: 1. There is a Pascal Newsletter. 2. I have been 
wasting my time thinking about what would make Basic better. 

"Please send me information on obtaining the Pascal Newsletter and any information you 
may have about implementations of Pascal on micros (particularly M6800's)." 
(* 78/01/19 *) 

Joseph M. Jolda, Bartlett High School, Negus St., Webster, MA 01570: "I've been trying 
to build something around the IBM Assembler but I'm running into all sorts of problems 
It seems as though Pascal has the possible answer for me." (* 78/01/09 *) 

Ralph Johnson , 1592 N. Broad, Galesburg, IL 61401: "I am rewriting Concurrent Pascal for 
the PDP-11/40 which should take about two weeks. If no one else has done this, I will 
send you the few changes that need to be made to the PDP 11/45 version." (* 78/01/04 *) 

Here and There With Pascal 



Adnnan Khan, 222/7, Block-E, (0pp. Walton Training Centre), Walton Road, Lahore, Cantt. , 
Pakistan: "I would like to get some knowledge about the new developments made after my 
contribution of Source Library Mechanism for Pascal 1900, under George III, which has 
also reduced the compilation time by one third. Ify project also involved translation of 
some NAG routines into Pascal." (* 78/01/17 *) 

James R. Kochanocicz , Dedicated Systems Inc., 180 N. Michigan Ave., Chicago, IL 60601: 
"We are presently using Pascal on a Sperry Univac V-76 series computer." (* 78/03/19 *) 

Charles Kuhlman, New York City Criminal Justice Agency, 305 Broadway, New York, NY 
10007: "We are preparing to gear up a DEC PDP 11/70 RSX-llP system and are 
contemplating use of Pascal for some applications. ... Do you know specifically of 
any RSX 11/70 versions of Pascal?" (* 78/03/06 *) 



thinking of writing a 



Roland L. Lee , 645 35th Ave., San Francisco, CA 94121: "I ^..^...^^..^ ^^ „^^^^..^ ^ 

compiler for the Z-80 and would like some information on existing resident Pascal 
compilers that you know of for the Z-80." (* 78/04/01 *) 

Alan M. Lesgold , LRDC Computer Facility, University of Pittsburgh, 3939 O'Hara St., 
Pittsburgh, PA 15260: "I would be interested in knowing of sources, if they exist, for 
a 6800 cross-compiler that would run on a PDP-10 or PDP-15 and also for a PDP-15 
compiler. I am very interested in implementing Pascal as our primary source language." 
(* 78/01/12 *) 

Bruce MacAnespie , 600 N. Hickory Ave., Apt. 18, Bel Air, MD 21014: "If you can supply me 
with any contacts or information regarding Pascal compilers or interpreters implemented 
on Burroughs B6700 or B7700 Computer systems, please send it by return mail. Having 
been a Burroughs Algol fan for some years, I am extremely interested in a language that 
promises to be the next generation of decent software implementation languages." 
(* 78/03/08 *) 

Mario Magidin, Direccion Genereal de Sistemas y Procesos Electronicbs , Subdireccion de 
Sistemas "B," Corregidora No. 8, Centro, Palacio Nacional, Mexico 1, D. F.: "We are the 
computing facility of the Mexican Ministry of Budget and Planning. With the aid of a 
CDC Cyber-173 we are supposed to satisfy all the computing requirements of the 
Ministry, thus, large, so-called commercial type systems are constantly under 
development and/or running at our place. 

"Up to now, all these systems have been programmed in COBOL, and although we are 
painfully aware of the shortcomings of this approach, (particularly with CDC's COBOL) 
our solutions were directed mainly towards the use of a preprocessor of the type of 
Weinberg's Metacobol. 

"The idea of replacing COBOL with PASCAL has arisen. I would deeply appreciate your 
comments on this idea." (* 78/03/31 *) 



Bill Marshall , Jr., Sanders Associates, Inc., 
praising and promoting Pascal for five years now . 
where my mouth is!" 



24 Simon St., Nashua, NH: 
. . it's about time I put 



'I've been 
my money 



Irv McKnight , 505 Cypress Point, No. 52, Mountain View, CA 94040: "I have an S-100 8080 
system with a NorthStar Disc. Several of us are looking into making the U.C San Diego 
Pascal system live in the NorthStar." (* 78/03/27 *) 

Ronald D. McRaney, P.O. Box 10097, Station 1, Houma, Louisiana 70360: "I am in the 
process of putting together a Pascal dedicated PDP 11/03 for my personal use. 
(* 78/01/04 *) 

J. Scott Merritt, 655 S. Fairoaks Avenue, Apt. L-216, Sunnyvale, CA 94086: "Tried to 

find CACM article mentioned on Page 87 of PUG 11. It wasn't in Dec. '77 or anywhere 

else I looked. Where can I find it?" (* 78/03/11 We don't really know either; will you 
^/rite to Amsterdam to ask? *) 

Rolf Molich, Software Development Manager, Dansk Data Elektronik Aps., Generaj torvej 6A, 
DK-2730 Herlev: "Further, I would appreciate it very much if you could tell me the name 
and address of any person or institution that you may have heard of who is currently 
developing a Pascal compiler (not an interpreter) for the< Intel 8080 microcomputer." 
(* 78/01/24 *) 
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Allan Moluf , 2317 Knob Hill, Apt. 9, Okemos, MI 48864: "I would like to suggest a new 
approach for Pascal compilers on small machines. Syntax table-directed parsing 
techniques are now getting acceptable error recovery and should result in much smaller 
compilers. If PUG members know of anyone working in this area, please suggest Pascal as 
a useful language to implement. Most of the code generation and library routines are 
available in a portable compiler, which should result in an easy project." 
(* 78/03/21 *) 

Freeman L. Moore , Department of Computer Science, Pearce 203-B, Central Michigan 
University, Mount Pleasant, MI 48859: "For your records, CMU has a Univac 1106 computer 
with our version of Pascal from U.S. Naval Undersea Center, by M.S. Ball, version 
1.1C4." (* 78/03/04 *) 



Olav Naess, Welhavensgt. 65, Bergen Norway: "I am interested in a 
the Z-80 system I am building." (* 78/01/17 *) 



Pascal compiler for 



Heidi L. Neubauer , Coordinated Sciences Lab, Univ. Of Illinois, Urbana, IL 61801: "I am 
using Pascal to write machine problems assigned in an operating systems course I am 
taking at the Univ. Of Illinois as a graduate student in Computer Science. Our class 
has used both standard Pascal and a souped-up version with concurrent processes and 
semaphores (still under development but workable)." (* 78/03/07 *) 

William I. Nowicki, CS.R.L. Tech B626, 2145 Sheridan Road, Northwestern University, 
Evans ton, IL 60201: "My special Interest is the implementations of Pascal for 
mini-computers, especially PDP-8's and PDP ll's." (* 78/01/08 *) 

David J. Pesec , 20130 Miller Avenue, Euclid, Ohio 44119: "I also am wondering if there 
is any copy of Pascal that will run on a Honeywell Series 60 processor." (* 78/01/30 *) 

David Powers , 2 59A Trafalgar St., Petersham NSW 2049, Australia: "I have a TEC-9900 
system (based on the TMS9900) on which I hope to eventually be able to use Pascal. I 
would therefore ask if you are able to assist in this — do you know of a Pascal compiler 
for the 9900, or of any way I could get (with a view to modifying for use with my 
system) the Pascal source for a compiler with a code generator for the PDP-11. . . or 
one of the other micros. 

"I have been working on an implementation of Pascal-S for the 6502 (using 4-byte words) 
in the form of a cross-compiler (based on the compiler part of the Wirth Pascal-S 
interpreter as implemented in Pascal) to an 'ICODE' which runs on an interpreter (only 
partially debugged, as yet, being a translation of Wirth's 'interpret' procedure) 
running in 4K (5K-6K with floating point) using the Jolt 'DEMON' monitor. Are you aware 
of any similar implementations having been undertaken? Has anyone done, to your 
knowledge, the apparently feasible, but rather time-consuming conversion of this 
compiler into Pascal-S?" 

Steven R. Rakitin, Combustion Engineering, Inc., Mail Stop 9488-4BB, 1000 Prospect Hill 
Road, Windsor, CT 06095: ". . . I am interested in the potential use of Pascal as a 
Process Design Language." (* 78/01/24 *) 

Mike Rebmann , Memorex Corp., Communications Div., San Tomas at Central Expressway, Santa 
Clara, CA 95052: "We are potentially interested in adopting Pascal as a replacement for 
assembly language for programming our 1380 front end communications processor. Does the 
User's Group have any information on adopting Pascal for this purpose? I would be 
especially interested in the following kinds of stuff: 1. Compiler development (cost, 
time, feasibility of using 'weird' hardware features), 2. Cutting over a software 
development group to use the language (planning training, phasing). 3. Compatibility 
with existing software— it would be very hard to justify rewriting our existing product 
line software. 4. Support software development — library system, loaders, etc." 
(* 78/03/03 *) 

D. Roberts, Computing Laboratory, University College of North Wales, Dean Street, 
Bangor, Gwynedd LL57 lUT, Wales, UK: "We have recently put H.H. Nagel's implementation 
of Pascal on our DECsystem 10." (* 78/03/17 *) 
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gan, Comshare, Inc., P.O. Box 1588, Ann Arbor, 



MI 



48106: 



. included some documentation on the Pascal compiler implemented on our 



company's computers. The use of the language is primarily for application production 
systems software. To date, COMSHARE has written marketable products in Pascal and we 
can currently cross-compile source for the Sigma 9 and an INTEL 8080 machine." 
(* 78/02/16 *) 

Jon D. Roland, Computer Retailers Assn., Micro Mart, 1015 Navarro, San Antonio, TX 
78205: "We plan to support Pascal and extensions thereof extensively during the years 
ahead. We expect Pascal and APL to emerge as the leading higher-level languages, 
although Cobol will probably remain popular among many of our business customers." 
(* 78/03/28 *) 

Richard Roth, 5 North Salem Road, Ridgefield, CT 06877: "I implemented P-2 stack machine 
on Micro-Data 810 (but never finished compiler) and would like to get Pascal running on 
8080/Z80 system under my disk OS (an advanced TOPS-10-like operating system)." 
(* 78/02/01 *) 

Beardsley Ruml, 2nd, 3045 Ordway Street, N.W., VJashington, DC 20008: "I would like to 
participate in [an implementation on a Z-80/8080] if possible but, if not, certainly 
want to be one of the first users." (* 78/01/25 *) 

Robert L. Schoenfeld , Rockefeller Univ., 1230 York Ave., New York, NY 10021: "Interested 
in Concurrent Pascal and Modula for laboratory applications." (* 78/03/23 *) 

Mike Settle , ICP, 2925 Merrell Road, Dallas, TX 75229: "I am not presently a user, BUT I 
X^ANT TO BE. I am particularly interested in 8080 and Z-80 implementations. I sure would 
like to see Pascal replace BASIC in the personal and home computing environment." 
(* 78/02/24 *) 

Al Shpuntof f , Morningside College, Sioux City, lA 51106: "I would be delighted to be 
able to teach some of our courses using the facilities of Pascal, but alas, we are 
still using an antique IBM 1130 computing system. Still, the widespread availablility 
of Pascal Compilers for mini-computer systems raised hopes. A direct question to one of 
the participants in these conversations brought forth the suggestiond that you would 
know of the existence of a Pascal Compiler for the 1130 if anyone would." 
(* 78/04/07 *) 

Michael L. Sieman , 6103 Harwood Ave., Oakland, CA 94618: "I would also be interested in 
knowing if the Pascal User's Group has available any other publications, particularly 
ones concerning the implementation of Pascal on small machines (I'm thinking especially 
of the DEC LSI-11 under the RT-11 system), or article indexes to past issues of the 
Pascal News (and are back issues available?)." (* 78/03/23 *) 

George A. R. Silver , Earlham College, Richmond, IN 47374: "I am particularly interested 
in any recent issues which have reviews of implementations of Pascal on PDP 11/70's." 

Roger Sippl, 1806 Toyon Lane, Newport Beach, CA 92660: "I learned Pascal while a student 
at UC Berkeley on the many versions of the compiler on a PDP 11/70, while it was being 
written and debugged. Not the recommended way to learn a language, but it had its 
merit. "I am now working as a consultant in California with a special interest in 
medical computer applications." 

James A. Stark , M.D., 485 34th St., Oakland, CA 94609: "My computer resources are: IBM 
370/148 at Univ. Of Calif. At San Francisco (Medical School) that has a batch Pascal 
compiler. UNIX at U.C. Berkeley has just completed the installation of a new 
interactive version by Joy, Graham, and Haley (complete with manual). I have a home 
brew 8080 with floppy on which I hope to install UCSD's version and a 6502 presently 
sitting that will be used to interface my I/O Selectric if and when I get a missing 
board from Numan Computer Exchange." (* 78/03/28 *) 

Quentin F. Stout , Dept. Of Mathematical Sciences, SUNY-Binghamton, Binghamton, NY 13901: 
"Finally, I would greatly appreciate it if you could tell me where I could obtain a 
Pascal compiler for an IBM 370/158 under VSl . We are an academic institution which 
cannot afford a large fee, so we would probably have to obtain it from another 
university." (* 78/03/17 *) 

Jeff S t roomer , 224 Heritage Lane, Exton, PA 19341: "Do you (or any of your readers) know 



CO 



I— ^ 



oo 



en 



of a way to get Pascal's IF-THEN-ELSE's into LL(1)? I already know how to monkey with 
with LL(1) tables to make the parser work the right way, but that's not what I'm 
interested in; I want a grammar that's truly LL(1)." (* 78/01/13 *) 



We have a 



Roy Touzeau, Computer Science Dept. , Univ. Of Montana, Missoula, MT 59812: 
version of Pascal for the DEC-10 working on the DEC-20." (* 78/03/07 *) 

Mike Travis , Interdata, Inc., 3080 Olcott St., Suite 125A, Santa Clara, CA 95051: "I 

have just received the KSU version of Pascal which runs on an INTERDATA 8/32. We are 

now in the process of bringing it up in a multi-terminal environment in our local data 
center." (* 78/02/13 *) 

Tim Walsh, 174 E. Maujer Street, Valley Stream, NY 11580: "I hope to implement a sub-set 
of Pascal on my 'KIU-1 expanded' sometime this year." (* 78/01/09 *) 

Bill Winspur , Mgr. , Computer Serv., Computer Dept. For Health Sciences, Univ. Of 
Manitoba, 753 McDermot Ave., Winnipeg, Manitoba R3E 0W3, Canada: "We are installing a 
CYBER 171 in March and plan to use Pascal on it. We are also getting into uProcessor 
applications and are particularly interested in a rumour of Pascal for the 8080." 
(* 78/02/03 *) 

C. Dudley Warner, 16345 Los Gutos Blvd., No. 41, Los Gutos, CA 95030: "I have Z80 based 
uC w/64K mem etc. — running Pascal under CP/M and USCD 'Pascal.'" (* 78/03/08 *) 

Anna W atson , 3705 Delwood Drive, Panama City, FL 32407: "My objective is to determine 
ratlher quickly whether we should specify a Pascal compiler in a new computer 
specification for use by our present Algol users. Hopefully, study of a Pascal Primer 
plus the Pascal News can indicate if Pascal can serve our needs." (* 78/03/20 *) 

Chip We ems , Dept. Of Computer Science, Oregon State Univ., Corvallis, OR 97331: "I 
enjoyed talking to Tim B[onham] at the W. Coast Comp . Faire. Tell him that I'm 
rewriting my Pascal summary card, and will send him a copy when it's finished." 
(* 78/03/28 *) 

John Wi throw , DEC, MR1-1/A86, 200 Forest St., Marlboro, MA 01752: "I'm using the Pascal 
compiler on the DECSYSTEMS (10 and 20) here at Maynard and Marlboro, MA; as well as 
implementing a Pascal (subset) compiler." (* 78/01/25 *) 



Sandra Wright , 
Downsview, Ont. 
early in 1978." 



Defence and Civil Inst. Of Environmental Medicine, P.O. Box 2000, 
M3M 3B9, Canada: "We plan on implementing Pascal under UNIX and RT-11 
(* 77/11/30 *) 



FRENCH/ENGLISH -- ENGLISH /FRENCH Pascal IDENTIFIERS 

(* We received the following list of correspondences between French and English Pascal 
identifiers from Patrick Ward at the University of Montreal. He credits Olivier Lecarme 
and Pierre Desjardins with the original translation. Since we expect this to be used 
simply as a reference by those reading programs in the other language, we are omitting 
CDC-specific identifiers and those local to Montreal. We also have a list made by A. 
Tisserant at Nancy. His list is slightly different. We'd appreciate some clarification 
from the Sous-Groupe Pascal about what is standard for the French identifiers. *) 



French 

abs 

allera 

alors 

arctan 

arrondi 

avec 

bas 

booleen 

car 

carac 



English 

abs 

goto 

then 

arctan 

round 

with 

downto 

boolean 

char 

chr 



English 

abs 

and 

arctan 

array 

begin 

boolean 

case 

char 

chr 

const 



French 

abs 

et 

arctan 

tableau 

debut 

booleen 

cas 

car 

carac 

const 



carre 
cas 


sqr 
case 


const 


const 


cos 


cos 


dans 
de 


in 
of 


debut 

detasser 

div 


begin 

unpack 

div 


ecrire 
ecrireln 


write 
writeln 


ensemble 


set 


entier 
entmax 


integer 
maxint 


entree 

et 

etiqu 


input 

and 

label 


exp 
faire 
faux 
fdf 


exp 
do 

false 
eof 


fdln 

fichier 

fin 


eoln 
file 
end 


f onction 


function 


haut 
impair 
j usque 
lire 
lireln 


to 
odd 
until 
read 
read In 


In 


In 


mettre 
mod 


put 
mod 


nil 


nil 


non 


not 


nouveau 


new 


ord 


ord 


ou 


or 


page 

paquet 

plusloin 


page 

packed 

forward 


pour 


for 


pred 

prendre 

procedure 


pred 

get 

procedure 


programme 

rac2 

recrire 

reel 

relire 


program 

sqrt 

rewrite 

real 

reset 


rendre 

repeter 

si 


dispose 

repeat 

if 


sin 


sin 


sinon 


else 


sortie 
struct 


output 
record 


succ 
tableau 
t ant que 


succ 

array 

while 


tasser 
texte 


pack 
text 


tronc 


trunc 


type 
var 


type 
var 


vrai 


true 



cos 

dispose 

div 

do 

downto 

else 

end 

eof 

eoln 

exp 

false 

file 

for 

forward 

function 

get 

goto 

if 

in 

input 

integer 

label 

In 

maxint 

mod 

new 

nil 

not 

odd 

of 

or 

ord 

output 

pack 

packed 

page 

pred 

procedure 

program 

put 

read 

read In 

real 

record 

repeat 

reset 

rewrite 

round 

set 

sin 

succ 

sqr 

sqrt 

text 

then 

to 

true 

trunc 

type 

unpack 

until 

var 

while 

with 

write 

writeln 



cos 

rendre 

div 

faire 

bas 

sinon 

fin 

fdf 

fdln 

exp 

faux 

fichier 

pour 

plusloin 

f onction 

prendre 

allera 

si 

dans 

entree 

entier 

etiqu 

In 

entmax 

mod 

nouveau 

nil 

non 

impair 

de 

ou 

ord 

sortie 

tasser 

paquet 

page 

pred 

procedure 

program 

mettre 

lire 

lireln 

reel 

struct 

repeter 

relire 

recrire 

arrondi 

ensemble 

sin 

succ 

carre 

rac2 

texte 

alors 

haut 

vrai 

tronc 

type 

detasser 

j usque 

var 

tantque 

avec 

ecrire 

ecrireln 
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Pascal ik the fjEWS 

Australian (* A national daily newspaper *), February, 1978: Article in the "Computers" 
section about the Australian Atomic Energy Commission's compiler for the IBM 360 and 
3 70 systems. 

Byte , April, 1978: A letter from Stephen Smith describing the status of his work on a 
Pascal compiler, based on a subset of Pascal, for microcomputers. He is now testing the 
parsing procedures on a DECsystem 10. 



Computer Weekly , February 23, 1978: NCR, 
implement a language based on Pascal. 



Dundee, Scotland, is beginning to design and 



Computerworld , March 20, 1978: Hewlett-Packard's new language for operating system 
implementation, Syspal, combines many features of Pascal, Modula, Euclid, and 
Concurrent Pascal. 

Computerworld , April 24, 1978: Richard Cichelli describes the "revolutionary" growth in 
use of Pascal, this despite the resistance of mainframe and system vendors. A short 
history of Pascal and the extent of implementations is presented. 

Computing , January 5, 1978: A letter to the editor from R. J. Allwood in response to 
David Barron's earlier article in Computing . Allwood announces his reasons for 
rejecting a changeover from FORTRAN to Pascal and states what a tempting new language 
would look like. 

Computing Europe , March 16, 1978: David Barron notes the choice of Pascal as a base for 
the U.S. Department of Defense language IRONMAN. 

DARCOM (U.S. Army Materiel Development and Readiness Command) sent letters to PUG 
members on February 1, 1978, asking for their responses to a series of questions about 
use and implementation of Pascal. Purportedly, DARCOM is selecting a standard system 
software programming language. (* DARCOM got your name by copying it from the published 
roster. PUG has a general policy of not releasing the roster in machine-retrievable 
form.*) 



Data-Link (* published by ACM-Los Angeles *), February 1978: G. S. Khalsa, managing 
partner of the Pasadena Byte Shop, is reported to view Pascal as becoming the standard 
language for micro business systems. 

Datamation , February, 1978: A short announcement about PUG and Pascal News with' 
information about how to join appeared in the "Source Data" section. 

Datamation , February, 1978: A proposed multiprocessor system for the U.S. Navy, 
constructed by Lawrence Livermore Laboratories in California, contains a Pascal 
compiler, developed under subcontract by the Computer Sciences Department of Stanford 
Univ. 

Instruments and Control Systems , December 1977: A report of a Pascal compiler under 
development by Texas Instruments to meet Dept. Of Defense specifications. The article 
suggests that TI's Pascal could become a de facto standard for minis and micros. Unlike 
Intel's PL/M, Pascal is not a proprietary language. 

Journal of the Hewlett-Packard General Systems Users Group , January /February 1978: A 
short article introducing Pascal and some of its features and containing information 



about how to join PUG. 

Mini-Computer News , April 27, 1978: A new Pascal software package for the DS990 packaged 
disk systems is announced by Texas Instruments. TI suggests that its Pascal, closely 
compatible with standard Pascal, has many applications in areas traditionally dominated 
by FORTRAN and COBOL. 



UMMUG (Publication of the Univ. Of Minnesota Microcomputer Users Group), The University 
of Minnesota's recent acquisition of Terak computers and with them UCSD's Pascal 
compiler /interpreter is discussed. 

Vogelback Computing Center Newsletter (Northwestern Univ.), April, 1978: In announcing a 
short course on Pascal, an article mentions the widespread acceptance of Pascal. 

CONFERENCES 

Australian Universities Computer Science Seminar, held February 23-24, 1978, University 
of New South Wales: 

(* We received a letter from Tony Gerber saying that "everyone (Carroll 
(* Morgan *), Ken Robinson, Arthur Sale, Jeff Tobias, ^ Gordon Cox from AAEC, 
myself) was there." In addition, Tony sent us copies of two papers read at the 
conference: 
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G. W. Cox and J. M. Tobias, "An Implementation of Pascal 
Business Machines or The Impossible Takes a Little Longer. 

(* From the abstract *) The programming language Pascal has successfully 
implemented for IBM360 and IBM370 computers under the OS/360 family of 
operating systems. The compiler is written in Pascal and fully supports 
Standard Pascal with some significant extensions. Interesting aspects of the 
relationship between the language and the IBM360 architecture are discussed. 
Surprisingly enough, the IBM360/370 general purpose architecture readily 
lends itself to an efficient implementation of a high-level language such as 
Pascal, although some features are impossible to realise. 

Experiences in attempting to encourage a body of scientists to use Pascal in 
preference to FORTRAN are drawn on, with the conclusion that until a revised 
standard for Pascal is achieved, Pascal will never become a universally used 
programming tool. 

Arthur Sale, "Mismatches and Conflicts Arising out of the Burroughs 
B6700/B7700 MCP and a Pascal Implementation." 

(* From the abstract *) This paper draws on experiences of implementing a 
Pascal compiler on a Burroughs B6700 computer. Since these machines are 
designed for high-level language programming- solely, and the operating system 
(MCP) is highly structured, the conflicts between the assumptions commonly 
made by Pascal adherents, or built into the language, and the facilities 
offered by the operating system posed some interesting conflicts which are 
examined herein. 

Universite de Nice, Informatique, Mathematiques et Automatique, Manifestations 
Informatiques de Juin 1978, conference to include a meeting of the Pascal sub-group on 
the 13th and 14th of June. 

(* Sorry we didn't know about this conference in time for the last issue. 
We'll hope to have titles of the papers presented by next time. *) 

Second West Coast Computer Faire, March 3-5, 1978, San Jose, California. (* Pascal News 
editor Tim Bonham attended. He collected a dozen PUG memberships and reported that he 
"could have sold 100 Pascal User Manuals and Reports on the floor for twice their 
price." He also saw several demonstrations of Pascal on micros. Several papers of 
special interest to Pascalers are part of the proceedings *): 
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Sassan Hazeghi and Lichen Wang, "A Short Note on High Level 
Microprocessors." 



Languages 
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PATCH (Univ. Of Notre Dame Computing Center's newsletter), March 1978: UND has 
installed Pascal. 



recently 



(* From the abstract *) In this note, some of the practical aspects of bridging the gap 
between high level programming language and computer hardware are discussed. Several 
possible strategies are considered and the method of half-compiling-half-interpreting 



is studied. In dealing with address space limitation (or tight memory situation) and 
slow speed of micro processors running an interpreter, a measurement and analysis 
technique is suggested. This analysis not only gives a good estimate of the timing and 
storage requirement before the actual implementation, it also helps to optimize the 
speed and storage usage of the implementation. The note concludes with some results 
concerning the implementation of the programming language Pascal on a family of 
micro-processors . 

H. Marc Lewis, "An Experimental Pascal-like Language for Microprocessors. 

(* From the abstract *) This paper describes an experimental Pascal-like high level 
language oriented to microprocessor implementation and use. The design criteria include 
modest memory requirements^ self -compilation, simplicity, reasonable access to hardware 
features, and ease of extensibility. Program structure, data declarations, and control 
structures are described and examples given. Novel features of the language are 
discussed. An appendix gives a foraial description of the language via syntax graphs. 

Chip Weems, "An Introduction to Programming in Pascal." 

(* From the abstract *) This paper will concentrate heavily on the use of the Pascal 

language at the beginner^ s level. A minimal knowledge of some other programming 

language such as FORTRAN, BASIC, or ALGOL is assumed. 

The areas which will be covered are simple and structured statements in Pascal, simple 

and structured data types, plus procedures and functions. Emphasis will be placed on 

using Pascal statements, although some discussion of the power of user defined data 

types will also be included^ 

A list of machine models for which implementations of Pascal are known to exist is 

provided as an appendix* 



IMPLEMENTATIONS 

Urs Ammann, "On Code Generation in a Pascal Compiler," Software Practice and Experience, 
7:3 (June- July 1977), 391-423. 

(* From the abstract, as reported in Computing Reviews , January 1978. *) "This report 
deals with code generation in a Pascal compiler. It gives insight into the run-time 
organization of data and the use of the hardware registers of athe underlying machine 
(a CDC 6400) . It is shown how the compiler maintains a description of the register 
contents and uses this description to generate efficient code. Several examples of 
compiled code are discussed." 

Forest Baskett, "The Best Simple Code Generation Technique for WHILE, FOR, and DO 
Loops," SIGPLAN Notices , 13:4 (April 1978), pp. 31-32. 

(* From the abstract *) "This code generation technique for WHILE, FOR, and DO loops is 
simple to implement and usually results in the best loop code in the absence of flow 
analysis. Also the technique makes it possible to move code from inner loops without 
doing flow analysis and without ever moving code from a less frequently executed block 
to a more frequently executed block." 

Kenneth L. Bowles, "The USCD Pascal Project," Educom , 13:1 (Spring, 1978), pp. 2-7. 
(* From the summary *) "Small stand-alone microcomputers can serve as the basis for 
running a sophisticated general-purpose interactive software system capable of 
supporting CAI, word processing, data processing, and other interactive tasks in 
addition to development of the software itself. The project described in this article 
has implemented such a software system using the Pascal programming language. The 
system is designed to be nearly machine-independent, and currently runs on a number of 
microprocessors, including the popular LSI-11, 8080, and Z80." 
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BOOKS AND ARTICLES 

PLEASE SUBMIT ALL NOTICES OF Pascal 

BOOKS, ARTICLES, ABSTRACTS, etc. 

to Rich for this section. Thanks, Andy. 

APPLICATIONS 



Editor: Rich Stevens 



Kitt Peak Nat'l Observatory 
P. 0. BOX 26732 
Tucson, AZ 85726 USA 

(phone: 1-602-327-5511) 



G. W. Cox and J. M. Tobias, "An Implementation of Pascal for International Business 
Machines or the Impossible Takes a Little Longer." (* See CONFERENCES section *) 

Sassan Hazeghi and Lichen Wang, "A Short Note on High Level Languages and 
Microprocessors." (* See CONFERENCES section *) 

H. Marc Lewis, "An Experimental Pascal-like Language for Microprocessors." (* See 
CONFERENCES section *) 

Arthur Sale, "Mismatches and Conflicts Arising out of the Burroughs B6700/B7700 MCP and 
a Pascal Implementation." (* See CONFERENCES section *) 
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Patricia R. Mohilner, "Using Pascal in a FORTRM^ Environment," Software Practice and 
Experience , 7:3 (June- July 1977), 357-362. 

(* Summary of a review by R.A. Jones in Co mputing Reviews , January 1978. *) Mohilner 

demonstrates some problems encountered in attempting to write graphical applications 

programs in Pascal when the existing library of plotting routines V7as written in 
FORTRAN. She shows the solutions to those problems, but the example suggests that the 
problems she describes will likely be encountered by all installations. 

V.A. Nepomniaschy, and L.V. Chernobrod, "Automatic Program Verification," Problems of 
Programming , 1976, pp. 63-80. 

(* From the English summary in the table of contents *) "Describing the preliminary 
version of the system for proving assertions about programs (SPRUT). The deduction 
system herein is Hoare^s system for proving correctness of programs. The input is a 
Pascal program with assertions. The verification condition generator outputs the list 
of lemmas to be proved by other blocks of the system. In algebraic and logical 
reduction of expressions simplification strategies are used, including axioms and lists 
of subgoals." 

Gary J. Nutt, "A Comparison of Pascal and FORTRAN as Introductory Programming 
Languages," SIGPLAN Notices , 13:2, February 1978, pp. 57-62. 

(* From the abstract *) "The Department of Computer Science at the University of 
Colorado has recently made the transition from FORTRAN to Pascal [in introductory 
courses] , and this paper offers and informal discussion of the experiences of one 
instructor during that change." 



J. Welsh, "Economic Range Checks in Pascal," Software — Practice and Experience , Vol. 8 
(1978), 85-97. 

(* From the abstract *) "A Pascal implementation is described which exploits the 
information provided by subrange type declarations to minimize the run-time checking 
involved in detecting range violations. An evaluation of its performance is given, and 
some possible modifications are discussed. (* It pays to use sub-ranges. *) 



LANGUAGES 

Borge Christensen, "COMAL: Structured Basic," People*' s Computers , 6:4 (Jan. -Feb. 1978), 
pp. 36-41. 
(* From the table of contents *) ". . . adding Pascal's algorithmic structures to 

BASIC." 

M. Iglewski, J. Madey, and S. Ma twin, "A Contribution to the Improvement of Pascal," 
SIGPLAN Notices , 13:1 (January, 1978), pp. 48-58. 

(* From the introduction *) "The purpose of this paper is twofold. First of all we 
would like to present some of our proposals, concerning the desirable corrections in 
the Revised Report on Pascal and possible slight extensions of the language. Secondly 
we want to argue with some of the critical remarks on Pascal as formulated several 
months ago by Conradi." 
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Charles Lakos and Arthur Sale, "Is Disciplined Programming Transferable, and is it 
Insightful?" (* Received in January; may be published by now; more news from Arthur 
Sale or from PN 13 *) 

(* From the abstract *) ". . . The paper applies the thought processes advocated by [ 
E.W.] Dijkstra to [two] problems and indicates the insights that the authors gained 
from this. In both cases algorithms new to the authors were derived, and the properties 
of these are also examined. The paper . . . demonstrates that the techniques advocated 
by Dijkstra are indeed transferable to other programmers, and that this transfer yields 
better insight into the activity we call programming." 

David Mundie, "Pascal vs. BASIC," People'' s Computers , 6:4 (Jan. -Feb. 1978), pp. 41-47. 
(* From the table of contents *) "A polemical comparison of the two as general-purpose 
microprocessor languages." 

Jim des Rivieres and Ted Venema, "Euclid and Pascal," SIGPLAN Notices . 13:3 (March 
1978) , pp. 57-69. (* From the abstract *) "The programming language Euclid was intended 
for writing system programs that could be verifiable by state-of-the-art verification 
methods. Since verification was not an explicit goal in the design of Pascal, it is not 
surprising that this gave rise to differences between the two languages. The Euclid 
designers intended to change Pascal only where it fell short of this goal. This paper 
examines differences in the two languages in the light of this objective. These 
differences are roughly grouped under the headings verification, system programming, 
and user-oriented changes." 

Abraham Silberschatz, Richard B. Kieburtz, and Arthur Bernstein, "Extending Concurrent 
Pascal to allow dynamic resource management," IEEE Transactions on Software Engineering 
, SE-3:3 (May 1977), 210-217. 

(* One sentence from a review *) "The authors of this paper propose an extension to the 
programming language Concurrent Pascal to allow more flexible dynamic resource 
management. They introduce a new type called manager . ..." 

Tennent, R. D., "Language design methods based on semantic principles," Acta Informatica 
, 8:2 (1977), 97-112. 

(* From the abstract *) "Two language design methods based on principles derived from 
the denotational approach to programming language semantics are described and 
illustrated by an application to the language Pascal. The principles are, firstly, the 
correspondence between parametric and declarative mechanisms, and secondly, a principle 
of abstraction for programming languages adapted from set theory. Several useful 
extensions and generalizations of Pascal emerge by application of these principles, 
including a solution to the array parameter problem, and a modularization facility." 

Arthur Sale, "Stylistics in Languages with Compound Statements" (* Article may have been 
published in Australia; check with Arthur Sale; more information in PN 13. *) 
(* From the abstract *) "This short communication discusses a stylistic problem which 
arises in languages with use both statement separators such as semicolons, and begin- 
end bracketting structures, such as Pascal. It suggests that an alternative to the 
traditional rules \diich have evolved from Algol 60 is preferable." 

Chip Weems, "An Introduction to Programming in Pascal." (* See CONFERENCES section. *) 

J. Welsh, W. J. Sneeringer, and CA. Hoare, "Ambiguities and Insecurities in Pascal," 
Software — Practice and Experience , Vol. 7 (1977), 685-696. 

(* This is the best critical article to have appeared about Pascal. The ambiguities 
discussed are equivalence of types (name equivalence vs. Structural equivalence), scope 
rules and one-pass compilation, and set constructors. The authors point out the 
following "insecurities": features whose implementation either risks undetected 
violation of rules of the language or run-time checking that is too expensive to be 
tolerable: variant records, functions and procedures as parameters, range violations, 
uninitialized variables, and dangling references. *) 



(* See reviews for Bowles, Conway, Grogono, and Schneider texts. *) 



S. Alagic and M. A. Arbib, The Design of Well-Structured and Correct Programs , New York: 
Springer-Verlag, 1978, 292 pages, $12.80. (* See description in No. 11. We hope to have 
a review in No. 13. *) 

Richard Kieburtz (* Updated information *), Structured Programming and Problem Solving 
with Pascal , Englewood Cliffs, NJ: Prentice-Hall, 1977, 320 pages, $12.80. (* Similar to 
Conway; see reviews. *) 

A Guide to PASCAL Textbooks 

Richard J. LeBlanc and John J. Goda 
School of Information and Computer Science 
Georgia Institute of Technology 
Atlanta, GA 

G. Michael Schneider, Steven W. Weingart and David M. Perlman, An Introduction 
to Programming and Problem Solving with PASCAL , John Wiley, 1978. ($12.95) 

Among the strongest features of this book are its coverage of the com- 
plete programming processes (from problem specification through debugging 
and maintenance) and its emphasis on good programming style. Most of 
PASCAL is well presented, with the examples giving a good demonstration 
of how the features of the language should be used. The weakest part 
of the book is the presentation of "advanced" features such as variant 
records and pointers. Its coverage of programming fundamentals makes 
this an excellent text for an introductory course for students with little 
or no programming experience. 

Peter Grogono, Programming in PASCAL , Addison-Wesley, 1978. ($9.95) 

While this is an introductory book, it concentrates more on the syntax 
of PASCAL and less on programming methodology than does the book by 
Schneider et. al. It is easy to read and has syntax charts integrated with 
the text rather than in an appendix. Grogano includes very good coverage 
of the advanced features, particularly pointers and dynamic data structures. 
The presentation of user-defined types is not as well-organized as it 
could be. lAThile this book could be used as the text for an introductory 
course, its lack of coverage of programming fundamentals and its strength 
in the area of the advanced features make it best for students who have 
some programming experience. 

Richard Conway, David Gries and E. Carl Zimmerman, A Primer on PASCAL , Winthrop, '76. 

($10.95) 
This book is based on a PL/1 book by Conway and Gries and it shows. 
The only structured type discussed is arrays and the discussion of user de- 
fined scalar types is very weak. The material on programming methodology 
is not at all integrated with the presentation of the language, so it is 
necessary to skip around in the book when it is being used as a text in an 
introductory course. There are errors in the presentation of PASCAL that 
are clearly not typographical. In general, this book fails to capture 
the idea that the features of PASCAL can actually make program development 
easier than if FORTRAN were being used. 

Kenneth L. Bowles, (Microcomputer) Problem Solving Using PASCAL , Springer- 
Verlag, 1977. ($10.95) ' 

(See PASCAL News #11 for a more thorough review.) This basically appears 
to be a good book, but the language presented is not standard PASCAL. Bowles 
microcomputer PASCAL (with extensions for graphics and string handling) is 
used and the examples are heavily dependent on use of the extensions. This 
tends to make much of the book confusing to a student who does not have 
Bowles' system available. 
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Articles Wanted 

(* Tim Bonham has been surveying publications which might want articles about Pascal and 
has supplied us with the following list. *) 

Wayne Green 

Kilobaud 

Peterborough, NH 03458 

(603) 924-3873 

Especially interested in articles which answer the questions "Why 'should I use 
Pascal?" "What uses does Pascal have in the real world?" and "How would I gain from 
using Pascal?" Maybe later on could use articles on how to program in Pascal. Will 
pay. 

Stan M. Sokolow 

Solus News 

1690 Woods ide Dr. 

Redwood City, CA 94061 

(415) 368-3331 

Wants articles introducing and "justifying" Pascal. Especially interested in 
machines which are software compatible with the SOL (8080-based with cassette 
operating system). 

Northstar Newsletter 
2547 Ninth St. 
Berkeley, CA 94710 

Especially interested in software for the Northstar products: micro disk system and 

Horizon computer system. Introductions and justifications. 

Larry Steckler, Editor 
Radio-Electronics 
200 Park Ave. S. 
New York, NY 10003 
(212) 777-6400 

Introductions to programming in Pascal. 

ROSTER INCREMENT ( 7 8 / '( / 2 2 ) 

The names listed below represent people who have renewed , changed address , 
or joined PUG since the roster increment was printed in PUGN 11 . Some 



interesting statistics: 
renew date number 
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78 
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79 
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80 


54 
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RUSSEL J. ABBOTT 

REESA ABRAMS 

RICtL\Rr) E. ADAl-lS 

TOOT ADDY^IAN 

PETER ALriANN 

J. AMBLER 

RICHARD M- AMEYE 

CHRISTOPHER AMLEY 

DAVID E. ANDERSON 

PETER ANDERSON 



state 

CA 
MN 
MA 
TX 
NY 
PA 



91330 
87106 
43214 
Ml 3 9PL UNITED KIMGDOM 
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UNITED KINGDOM 
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UK 
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88 
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Australia 
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number 

349 
156 
107 
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ATTENTION: GORDON R. SHERMAN 

ATTENTION: G. TER HOFSTEDE 

ATTENTION: JERRY W. SEGERS 

ATTENTION: R. D. BERGERON 

ATTENTION: SANDRA miGHT 

ATTN: BETTE BOLLING-LIBRARIAN 

ATTN: CECICO 

ATTN: CENTRE DE RECHERCHE 

ATTN: CHICO PROJECT - CDC 

ATTN: COMPUTER SCIENCE PRESS INC. 

ATTN: CUPERTINO LIBRARY 

fiTTN'. DEPT DE MATHEMATIQUE AND INFOR!-IATIQUE 

ATTN: DEPT OF BIOCHEMISTRY 

ATTN: DEPT. OF COMPUTER SCIENCE 

ATTN: DOCUMENTATION OFFICER 



37916 
M5V 2S9 CANADA 

30332 

03824 
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45036 

CHILE 
F-34075 FRANCE 

95929 

20854 

95014 
F-35031 FRANCE 
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38677 
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ATTN: FREIE UNIVERSITAT BERLIN 

ATTN: FRIEDA S. COHN 

ATTN: HELEN SMITH 

ATTN: INFORMATION SERVICE CENTER 

ATTN: INSTITUT FUER INFORl-lATIK 

ATTN: INSTITUT FUR INFORMATIK 

ATTN: LAFAYETTE COLLEGE 

ATTN: LIBRARY 

ATTN: LIBRARY - COPY 2 

Rrf'N : NORTHWEST MICROCOMPUTER SYSTEMS INC. 

ATTN: PROGRAMMING ADVISOR 

ATTN: PROGRAMMING ADVISOR 

ATTN: PURCHASING OFFICE 

ATTN: SAM CALVIN 

ATTN: SCHOOL OF INFORI-fATIOH SCIENCES 

ATTN: SERIALS DEPT. 

ATTN: SPECIAL INTERACTIVE COMPUTER LAB 

ATTN: STUDENT COMPUTING COOP 

ATTN: SUSAN BOWIE - DOCUMENTS ROOM 

ATTN: THE LIBRARIAN 

ATTN: UNBOUNDED COMPUTING 

ATTN: UNIVERSITAT DE GRENOBLE 

l^ffN: TECHNICAL RESEARCH CENTRE OF FINLAND 

LEE D. AURICH 

ROBERT M. BAER 

C. BAILEY 

F. T. BAKER 

JOHJl BANNING 

ANN BARDIN 

ANN V. BARROW 

FRANCIS H. BEARDEN 

E. R. BEAUREGARD 

GARY BECKWITH 

M. D. BEER 

DAVID A. BEERS 

E. MAURICE BEESLEY 

DAVID J. BELL 

ABDUL RASAQ BELLO 

STEVEN M. BELLOVIN 

GILBERT BERGLASS 

ALLEN BERGLUND 

THOMAS B BRIBER 
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SCOTT S. BERTILSOH 

K. S. BHASKAR 
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CHRIS M. BISHOP 
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W. ASHBY BOAZ 

PETER BOCK 

JOHN R. BOGAN 
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SCOTT CRUMPTON 
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THOMAS DANBURY 

RONALD L. DANIELSON 

GENE A. DAVENPORT 

SCOTT T. DAVIDSON 

ADELIMO CARLOS DE SOUSA 

DENNIS S. DELORME 

ALAN DELWICHE 

SHAUN DEVLIN 

JERRY DI MASSA 

ROBERIO DIAS 

DAVID R. DICK 

CLEMENT L. DICKEY 

MARY DIEGERT 

BOB DIETRICH 

M. JEAN -MARIE DIRAJID 

FELIX DREHER 

LARRY DUBY 

DOUGLAS DUtlLOP 
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JOHN EDVIARDS 
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H. W. EGDORF 
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ERIC D. FREY 

DAVID F. FRICK 

KARL FRYXELL 
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RICHARD D. GEORGE 

CARSON GERMAN 

BRANKO J. GEROVAC 
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CHARLES J. GIBBONS 

RICK GILLIGAN 

DON GILMORE 

THO^IAS GIVENTER 
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GEORGE H. GOLDEN SR. 
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DAVID N. GRAY 
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SY GREENFIELD 
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OTLLIAM L. HAFNER 

JACQUES HAGUEL 

BYRON HALE 

RICHARD W. HA!1ILT0N 

BRIAN HANSEN 

WILL HAPGOOD 

ANDY HARRINGTON 

MIKE HARRIS 



T2N 1N4 CANADA 

UNITED KINGDOM 

75248 
SEl OAA UNITED KINGDOM 

95070 

02193 

03301 

95014 

68583 

19898 
HIG 3S5 CANADA 

97005 

01701 

93940 

92277 

32601 

47904 

08108 

06880 

95051 

10016 

92138 

PORTUGAL 

55901 

95120 

48010 

95051 

BRAZIL 

02104 

93407 

13902 

97077 
J IK 2R1 CANADA 

66762 

22209 

23185 

94040 
3083 i 
3216 - 

80401 

88003 
BT7 INN UNITED KINGDOM 

08046 

98040 

08*40 
SF-00100 FINLAND 

06504 

60919 

22901 

95014 

95118 

02154 

94611 

03060 



-a 
oo 

3> 






I AUSTRALIA 
. AUSTRALIA 



OO 



UNITED KINGDOM 



03031 
94025 
91125 

F-31450 
55113 
22301 
60439 
90706 
02154 
55343 
68154 
93407 
95030 
10583 
94087 
14063 
02174 
15108 
35223 
94720 
78769 
19311 

V4M 3T9 
12206 

19174 
19424 
JIK 2R1 ( 
94043 
94702 
97213 
02154 
93017 
62704 



CANADA 
CANADA 



3> 
CD 



ROBERT 0. HARRIS WCIA OAH UNITED KIMGDOtI 



ROBERT W. HARRIS 


2II14 


DOK HARVEY 


97070 


W. F. HAYGOOD 


84121 


PETER HAYNES ] 


L5N i:<7 CANADA 


SASSAN HAZEGHI 


94305 


RANDALL HEAP 


01752 


JOHN HEATH 


04103 


JUDY HERRON 


91789 


S. J. HIGGINS 


CA9 3LP UNITED KI>JGDOM 


TERUO HIKITA 


158 JAPAN 


BUZZ HILL 


98632 


BRUCE HILLEGASS 


01754 


ED HIRAHARA 


83704 


THOH HOARD 


55414 


C. A. R. HOARE 


0X2 6PE UNITED KINGDOM 


FRED H. HOFKIf? 


19117 


WILLIAM HOLMES 


63110 


JAMES W. HOLT JR. 


40222 


JILL A. HOLTZ 


63166 


WILLIAM C. HOPKir^S 


19335 


MARK HORTON 


53706 


DAVID A. HOUGH 


24502 


MICHAEL A. HOUGHTALIMG 


85712 


D. J. HOWORTH 


UNITED KINGDOM 


PEI HSIA 


35801 


PETER YAN-TEK. HSU 


55455 


HARTMUT G. HU3ER 


22448 


GARY HUCKA3AY 


73501 


JACK HUGHES 


K7L 3N6 CANADA 


PHIL HUGHES 


98507 


EDWARD C. HUMPHREY 


78769 


M. A. HUSBAND 


UNITED KINGDOM 


DANIEL C. HYDE 


17837 


ELIZABETH IBARRA 


91360 


MICHAL IGLEWSKI 


00590 POLAND 


BERT INGARFIELD 


77459 


DAVID IHTERSIMOHE 


90250 


T. M. M. IRISH 


NP6 7BB UNITED KINGDOM 


PORTIA ISAACSON 


75080 


HANNU JAAKKDLA SF-33500 FINLAND 


TIMOTHY H. JACKIMS 


94306 


STEVE JAY 


85721 


ROM JEFFRIES 


93017 


JOSEF JINOCH 


7 CZECHOSLOVAKIA 


DOUGLAS N. JOHNSON 


94598 


LYTLE JOHNSON 


80033 


PAUL D. JOHNSON 


75006 


RALPH JOHNSON 


61401 


ROBERT T. JOHNSON 


87545 


S. JOHNSON 


85002 


JOSEPH H. JOLDA 


01570 


ALAN JONES 


IRELAND 


DAVID JONES 


L5N 1K7 CANADA 


RUSSELL JONES 


M5M 3W6 CANADA 


MARK JUNGWIRTH 


93010 


MIKE KAimAD 


55413 


KENNETH KAPLAN 


50304 


HEIKKI KASKELMA 


SF-00130 FINLAND 


RICHARD KAUFMAN 


92093 


FRED J. KELLER 


99210 


MIKE KERSEY 


77098 


ADNNAN KHAN 


PAKISTAN 


JOHN H. KILFOIL 


95126 


ERICH R. KNOBIL 


33313 


TOM KNOC}!E 


92109 


STEPHEN KOCH 


01730 


JAMES R. KOCIUNOWICZ 


60601 


JUDITH KOVETZ 


ISRAEL 


JEFF KRAVITZ 


11771 


DIETRICH KREKEL 


D-5000 GERMANY 


RICHARD W. KREUTZER 


84102 - 


CHARLES KUHLMAN 


10007 


DARRYL KUHNS 


89503 


KWAI-SAND LAM 


D-4440 GERMANY 


K. LANG 


B15 2TT UNITED KINGDOM 


GUY LAPALME 


H3C 3J7 CANADA 


G. F. LAPPIN 


UNITED KINGDOM 


JOHN LATRASH 


20910 


CHARLES L. LAWSON 


91103 


HENRI A. LE FRIANT 


70118 


RONALD LEBEL 


02139 


RICHARD LEBLANC 


30332 


ROLAND L. LEE 


94121 


R. GARY LEE 


32306 


WILLIAM J. LEE 


55423 


E. J. LEGGE 


M60 IQD UNITED KINGDOM 


CLARENCE LEHMAN 


55364 


CHARLES T. LEIS 


94087 



WILL LELAND 
JOE LERNER 
ALAN M. LESGOLD 
KEN LESSEY 
JAMES D. LETZ 
DAVID J. LEWIS 
HORNG JYH LIANG 
PING K. LIAO 
JACK LIEBSCHUTZ 
JOHN E. LIND 
FRANK LINDSAY 
CHUI FAN LIU 
WILLIAM R. LLOYD 
CARLO LOCICERO 
STEPHEN A. LONGO 
ANTHONY P. LUCIOO 
CLARENCE W. LYBARGER 
STUART LYNNE 
BRUCE HAC ANASPIE 
D. W. MACLEAN 
ORLANDO S. MADRIGAL 
KEVIN T. MAHONEY 
DENNIS J. MAINE 
STEPHEN MANN 
DUANE F. MARBLE 
THO^IAS A. MARCINIAK 
L. R. MARKER 
BILL MARSHALL 
WILLIAM J. MARSHALL 
S. I-IATTHEWS 
STEVE MCFERRIN 
FRANK E. MCGARRY 
JAMES PATRICK MCGEE 
JAl-ES A. MCGLINCHEY 
DAVID J. MCKEE 
IRVINE L. MCKNIGHT 
WILLIAM L. MCLAIN III 
RONALD P. MCRANEY 
JOHN MEDCALF 
MICHAEL MEEHAN 
JIM MERRITT 
HANS J. METZDORF 
KURT METZGER 
JC'EPH MEYER 
R. N. MILLER 
PATRICIA R. MOHILNER 
ROLF MOLICH 
UFFE MOLLER 
ALLAN MOLUF 
CECIL A. MOORE 
FREEMAN L. >»ORE 
RAYMOND MOREL 
CLEMENT MORITZ 
LYALL MORRILL 
GREG MORRIS 
JWO-W MOU 
GLEN R. J. MULES 
ANN MURPHY 
CHARLES MYERS 
DONALD V. >IYHRA 
J. P. M. STOFBERG 
GERALD NADLER 
OLAV NAESS 
JOHN NAGLE 
GEORGE NAGY 
T. A. NARTKER 
ED NAYLOR 
PETER A. NAYLOR 
HEIDI L. NEUBAUER 
MARTIN NICHOLS 
DANIEL NICHOLSON 
DENNIS NICHOLSON 
HIROAKI NISHIOKA 
TOOT NOE 
JOHN NOLD 
MELVIN L. NORELL 
BARBARA K. NORTH 
LARRY T. NOVAK 
WILLIAM I. NOWIGKI 
M. NUNN 
FRANK NUSSEAUM 
FRANK W. OECHSLI 
DAVID F. OHL 

ERIC OLSEN 

GENE H. OLSON 

JAMES B. OHEY 

P. E. OSMON 

SUSAN S. OWICKI 



53715 
38163 
15250 
97051 
92805 
14850 
20854 
94545 
02139 
55455 
22209 
60005 
94115 
L5L 2E9 CAIUDA 
19141 
77843 
55901 

CANADA 
21014 
S7N OWO CANADA 
95929 
01742 
92717 
01730 
14260 
20014 
35805 
03060 
98033 
H4J INl CANADA 
94086 
20771 
77025 
19403 
22209 
94040 
27410 
70360 
94707 
02133 
94086 
CH-6900 SWITZERLAND 
48105 
17557 
75229 
80523 
DK-2730 DENMARK 
D:K-9220 DENMARK 
48864 
95051 
48859 
CH-1224 SWITZERLAND 
01720 
94114 
54701 

CHINA 
10804 
20742 
60611 
92705 
19422 
01351 

NORWAY 
95051 
68588 
87801 
78761 
19422 
61801 
07801 
55901 
19401 

544 JAPAN 
91711 
15701 
90070 
66502 
75235 
60201 
SWIP 4RT UNITED KINGDOM 
69626 
94611 
95014 

92713 
55419 
9^022 
NW3 7 ST UNITED KINGDOM 
94305 



JAMES N. O'BRIEN 


97229 




STEVE O'KEEFE 


20229 




JACK PAGE 




SINGAPORE 


W. 0. PAINE 


91103 




R. L. PALASEK 


44839 




RICHARD PALCHIK 


95014 




PAUL J. PANTANO 


95051 




T. L. (FRANK) PAPPAS 


19083 




M. L. PATRICK 


B20 ILL 


UNITED KINGDOM 


DAVID N. PECK 


01756 




JIM PECK 


16142 




ROBERT C. PERLE 


08753 




BERNARD PERRETTE 


F-92803 


FRANCE 


RONALD H. PERROTT 


94086 




DAVID PESEC 


44119 




JAMES L. PETERSON 
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SUSAN A. PETERSON 


55432 




CHRIS K. PHILLIPS 


94305 




DAVID M. PHILLIPS 
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DAVID PICKENS 


80302 




THOMAS PIRNOT 


19530 




FRED POSPESCHIL 


68005 




DAVID POWERS 


2049 


AUSTRALIA 


KARL PRAGERSTORFER 


A-4060 AUSTRIA 


GENE H. PRIESTMAN 


95129 




FRANK PROSSER' 


47401 




ANDREW S. PUCHRIK 


47119 




J. R. PUGH 


SI IWB 


UNITED KINGDOM 


SHING-KIN PUN 


95926 




ABBAS RAFII 


73019 




ROBERT J. RAKER 


94104 




STEVEN R. RAKITIN 


06095 




TIM RAND 


06258 




ROBERT RAN SD ELL 


43202 




DONALD D. REDDING 


48105 




WERNER REMMELE 


D-8000 GERtiANY 


JOHN H. REMMERS 


48197 




TIMOTHY P. ROBERTS 


10509 




KEN ROBINSON 


2033 


AUSTRALIA 


D. J. ROBSON 




UNITED KINGDOM 


MICHAEL RODBY 


50701 




JAMES D. ROGAN 


48106 




J. S. ROHL 


6009 


AUSTRALIA 


JON D. ROLAND 


78205 




GENE ROLLINS 


11794 




J. ROSCOE 




UNITED KINGDOM 


PETER N. ROTH 


22030 




RICHARD ROTH 


06377 




R. WALDO ROTH 


46989 




H. J. ROWE 


LEI 7RH 


UNITED KINGDOM 


HERB RUBENSTEIN 


80401 




BEARDSLEY RUfIL 2ND 


20008 




HOWARD RUTIEZER 


60025 




JOHN L. RUT IS 


97106 




DAVID W. SALLUME 


93454 




ANN D. SANDERSON 


23284 




TOM SANDERSON 


91311 




HAROLD S. SCHECHTER 


11418 




ALAN M. SCHLENGER 


95064 




CH. SCHLIER 


D-7300 


GERMANY 


RICHARD SCHLOTFELDT 


55435 




ANA-MARIA SCHMIT 


CH-1007 


SWITZERLAND 


ED SCHOELL 


95051 




ROBERT L. SCHOENFELD 


10021 




PETER U. SCHULTHESS 


CH-8006 


SWITZERLAND 


JIM SCHULTZ 


95014 




WILLIAM M. SEIFERT 


87545 




MICHAEL SETTLE 


75229 




LEONARD SHAPIRO 


58102 




T. K. SHARPLESS 


10021 




TIMOriY SHAW 


20016 




ALAN M. SHERKOW 


53212 




BRUCE SHERRY 


95050 




R. G. SHERRY 


98107 




THOMAS E. SHIELDS 


77005 




KEITH ALLAN SHILLINGTON 


92093 




CHARLES B. SHIPMAIJ JR. 


22027 




KIM L. SHIVELEY 


75231 




ARNOLD SHORE 


22032 




MICHAEL L. SIQ-ION 


94613 




LESLIE L. SIFTER 


02181 




JOHN SIGLE 


78284 




GEORGE A. R. SILVER 


47374 




GENE SIMMONS 


22030 




TIMOTHY M. SIMmNS 


72143 




SIMON 


2308 


AUSTRALIA 


AiJDREW SINGER 


02556 




ROGER SIPPL 


92660 




DAVID SKINNER 


97330 





LEO J. SLECHTA 


55165 




JOSEPH W. SMITH 


92127 




TOM SNYDER 


92634 




DAVID SOLOMONT 


02155 




RICHARD P. SPRAGUE 


92714 




ROB SPRAY 


75207 




R. E. STARCK 


15021 




JAMES A. STARK 


94609 




R. A. STASIOR 


13083 




MICHAEL K. STAUFFER 


95051 




GREG STEPHEN 


62026 




WIM STEVENS 


B-2510 


BELGIUM 


JIM STEWART 


08854 




ZHAHAI STEWART 


80306 




RICHARD A. STONE 


55435 




QUENTIN F. STOUT 


13901 




M. J. STRATFORD-COLLINS 


06720 




GORDON STUART 


V8P 5J2 


CANADA 


INDRO S. SUWAfH)I 




INDONESIA 


MARK A. SWANSOH 


02174 




ROBERT M. SWEENEY 


38103 




E. SWEET 


48109 




KEN SYLVESTRE 


YIA 3P5 


CANADA 


DAVID TARASAR 


01581 




H. TAYLOR 


KIN 6N5 


CANADA 


R. F. TAYLOR 


90026 




DON TERWILLIGER 


97005 




DANIEL THALMAJffl 


H3C 3J7 


CANADA 


K. TIZZARD 


EX4 4PU 


UNITED KINGDOM 


HOWARD E. TOMPKINS 


15701 




ROY TOUZEAU 


59812 




MIKE TRAVIS 


95051 




TOM A. TRDTTIER 


M4R 1V2 


CANADA 


JAMES TRUEBLOOD 


19713 




JJIM TSEVDOS 


15213 




HOVJARD L. TURETZKY 


80220 




GERALD F. UHLIG 


55112 




S. M. VAIDYA 


411007 


INDIA 


TOM VAN DER HOEVEN 




THE NETHERLANDS 


STANLEY C. VESTAL 


55413 




JOHN VINSEL 


03061 




LES VOGEL 


93940 




PATRIK WAHREN 


S-102 62 


STffiDEN 


SCOTT WAKEFIELD 


94305 




JOHN WALKER 


94941 




JUSTIN C. WALKER 


20234 




TIM WALSH 


11580 




P. R. WAHWI 


KT23 3EZ 


UNITED KINGDOM 


C. DUDLEY WARNER 


95030 




SANDY WARSHAW 


12301 




MARK S. WATRRBURY 


22044 




ANNA WATSON 


32407 




CHIP WEEMS 


97331 




STEPHEN J. WEINBERGER 


64138 




STEVEN W. WEINGART 


01581 




LAUREN WEINSTEIN 


90025 




MICHAEL D. WINSTOCK 


32548 




DAVID H. WELCH 


92501 




JAMES H. WELLS 


92634 




D. R. WESTLUND 


K9K IJl 


CANADA 


MARVIN WHITE 


97077 




RONALD C. WHITES 


92701 




MAREK WIECHULA 


B2G ICO 


CANADA 


JACK M. WIERDA 


60532 




J. F. WILKES 




THE NETHERLANDS 


ROY A. WILSKER 


02114 




MICHAEL WIMBLE 


52404 




BILL WINSPUR 


R3E 0W3 


CANADA 


JOHN WITHROW 


01752 




ERIC WOGSBERG 


94618 




BRUCE WOLFE 


94965 




SHARLEEN WONG 


94134 




STEPHEN C. WOOD 


87108 




ARDEN WOOTTON 


64151 




FJLTON \JRIGHT JR. 


86301 




BRUCE YALE 


92506 
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01570 JOSEPH H. JOLDA/ BARTLETT HICH SCHOOL/ NEGUS STREET/ WEBSTER M A 01570 

01581 DAVID TARABAR/ SOFTWARE DEVELOPMENT/ M.S. 71141/ DATA GENERAL CORPORATION/ ROUTE 9/ WESTBORO MA 01581/ (617) 366-8911 XinS") 

01581 STEVEN W. WEINGART/ MS 71141/ DATA GENERAL CORP./ 15 TURNPIKE RD./ WESTBORO MA 01581/ (617) 366-3911 

01701 LAWRENCE F. CRAM/ 1300 WORCESTER RD. APT 101/ FlUMINGTOH MA 01 701/ (617) 875-5663 

01720 CLEMENT MORITZ/ 30 WETHERBEE ST./ ACTON MA 01720/ (617) 263-27 ^ 

01730 STEPHEN KOCH/ 3M/LIN0LEX SYSTEMS INC./ 10 CROSBY DRIVE/ BEDFOR MA 01730/ (617) 275-1420 X175 

01730 STEPHEN MANN/ 3H LINOLEX SYSTEMS INC./ 10 CROSBY DRIVE/ BEDFOR ° '^^ 01730/ (617) 275-1420 X164 

01742 KEVIN T. MAHONEY/ MAIL-STOP 2/ GENRAD INC./ 300 BAKER AVENUE/ CONCORD MA 01742/ (617) 369-4400 X317 

01752 RICIURD M. AMEYE/ 18 ROYAL CREST DR. - APT. 4/ MARLBORO HA 017 ^^^ ^^^^^ ^81-5823 

01752 RANDALL HEAP/ MR2-3/M84/ DIGITAL EQUIPMENT CORP./ 1 IRON WAY/ ''AW-BORO MA 01752/ (617) 481-9511 X634S 

01752 JOHN WITHROW/ MR1-1/A86/ DIGITAI. EQUIPMENT CORP./ 200 FOREST S '^•1 MARLBORO MA 01752 

01754 BRUCE HILLEGASS/ ML 22-1 /B40/ DIGITAL EQUIPMENT CORP./ 146 MAI " STREET/ MAYNARD MA 01754 

01756 DAVID N. PECK/ BELLINGHAM STREET/ MENDON MA 01756/ (617) 478-2 ^^0 

01778 ROBERT E. 3LANT0N/ ADVANCED DEVELOPMENT LABORATORY/ BOX J9/ RA ''THEON COMPANY/ BOSTON POST ROAD/ WAYLAUD tU 01778/ (617) 358-'>721 X''315 

01821 JOEL BERSON/ MS 895A/ HONEYWELL INFORllATION SYSTEMS/ 300 CONGO RD ROAD/ BILLERIGA MA 01321/ (617) 667-3111 

01851 GERALD NADLER/ DEPT 46/ WANG LABS/ 1 INDUSTRIAL AVE/ LOWELL MA 01851 

01854 GEORGE P. CHENEY/ ELECTRICAL ENGINEERING DEPT./ UNIVERSITY OF LOWELL/ 1 UNIVERSITY AVE./ LOWELL MA 01854/ (617) 454-7311 X259 

02104 DAVID R. DICK/ SOFTWARE INNOVATIONS INC./ P.O. BOX 1537/ BOSTO N MA 02104/ (617) 734-4200 

02114 ROY A. WILSKER/ COMPUTER NETWORK/ MASS. STATE COLLEGE/ 150 CAU SEWAY STREET/ BOSTON MA 02114/ (617) 727-9500 

02115 JENNIFER CLARKE/ COMPUTATION CENTER/ 25 RICHARDS HALL/ NORTHEA STERN U./ 360 HUNTINGTON AVE./ BOSTON MA 02115/ (617) 437-3133 

02138 MICHAa MEEHAN/ WINTHROP PUBLISHERS/ 17 DUNSTER STREET/ CAMBRI DGE MA 02138/ (617) 868-1750 

02139 RONALD LEBEL/ 344/ MIT/ 545 TECHNOLOGY SQUARE/ CAMBRIDGE MA 02 139/ (617) 253-3473 
02139 JACK LIEBSCHUTZ/ 320 MEMORIAL DRIVE/ CAllHRIDGE MA 02139/ (617) 494-8335 

02154 RONALD V. BOSSLET/ GTE LABS INC./ 40 SYLVAN ROAD/ WAI.THAM MA 2154/ (617) 890-8460 X338 

02154 F. G. FLETCHER/ EKS CENTER/ 200 TRAPELO ROAD/ WALTHAM MA 02154 / (617) 893-3500 XI 57 

02154 BRANKO J. GEROVAC/ EUNICE KENNEDY SlIRIVER CENTER/ 200 TRAPELO ROAD/ WALTHAM MA 02154/ (617) 893-3500 X157 

02154 WILL HAPGOOD/ RAYTHEON CORP./ FOUNDRY AVE./ WALTHAM MA 02154/ (617) 899-3400 X4520 

02155 DAVID SOLOMONT/ COMPUTER SERVICES/ MILLER HALL/ TUFTS UNIVERSI TY/ MEDFORD MA 02155/ (617) 623-0501 
02174 DAVID GRABEL/ 154 MADISON AVE./ ARLINGTON MA 02174 

02174 MARK A. SWANSON/ 71 BEACON STREET/ ARI.INGTON MA 02174/ (617) 6 43-4469 

02181 LESLIE L. SIFTER/ HONEYWELL/ 70 VJALNUT STREET/ WELLESLEY MA 02 181 

02193 TERENCE M. COLLIGAN/ RIVERSIDE OFFICE PARK/ MANAGEMENT DECISIO „ ovoTruc tm^ i nTw^„or,^„ ^^.^ / „ ™ „ , 

02556 ANDREW SINGER/ P.O. BOX A-67/ NORTH FAI.MOUTH MA 02556/ (617) 5 ^o!!"™ ' ^'^''''^"'' ^"^"^ "'^'^™" ''^ °2193/ (617) 391-0335 

03031 ERIC D. FREY/ FREY ASSOCIATES INC./ CHESTNUT HILL ROAD/ AHHERS T NU 03031/ (603) 472-5185 

03060 CRAIG FRANKLIN/ FUNCTIONAL AUTOMATION/ 118 NORTHEASTERN BLVD./ NASHUA NH 03060/ (603) 382-1580 

03060 BILL MARSHALL/ SANDERS ASSOCIATES INC./ 24 SIMON ST./ NASHUA N H 03060 

03061 JOHN VINSEL/ NCAl-3220/ SANDERS ASSOCIATES INC./ 95 CANAL STKE ET/ NASHUA NH 03061/ (603) 885-5314 
03301 ANTHONY CONTI/ P.O. BOX 1201/ CONCORD NH 03301 

03824 ATTENTION: R. D. BERGERON/ DEPT. OF flATH. AND COMPUTER SCIENCE / KINGSBURY HALL/ U OF NEW HAMPSHIRE/ DURHA;i NH 03824/ (603) 362-2321 

04103 JOHN HEATH/ DEPT. OF MATH. AND COMPUTER SCI./ UNIV. OF MAINE/ PORTLAND ME 04103/ (207) 780-4225 

06095 STEVEN R. RAKITIN/ M.S. 9488-4BB/ COMBUSTION ENGINEERING INC./ 1000 PROSPECT HILL RD./ WINDSOR CT 06095/ (203) 688-1911 X26''6 

06268 TIM RAND/ P.O. BOX 98/ STORRS CT 06268 

06504 C. B. FALCONER/ YALE - NEW HAVEN HOSPITAL/ 6016 CB/ YALE SCHOO L OF MEDICINE/ 789 HOWARD AVE./ NEW HAVEN CT 06504/ (203) 436-''603 

06720 M. J. STRATFORD-COLLINS/ DEPT. 310/ 40 BRISTOL STREET/ WATERBUR Y CT 06720/ (203) 756-4451 X285 

06877 RICHARD ROTH/ 5 NORTH SALEM ROAD/ RIDGEFIELD CT 06877/ (203) 4 38-3954 

06880 THOMAS DANBURY/ SURVEY SAMPLING INC./ 155 E. BOSTON POST RD./ WESTPORT CT 06380/ (203) 226-1321 

07102 PETER ANDERSON/ COMPUTER AND INFO SCI DEPT./ NEW JERSEY INSTIT UTE OF TECHNOLOGY/ 323 HIGH STREET/ NEWARK NJ 07102/ (201) 645-5126 

07801 MARTIN NICHOLS/ 100 GUY STREET/ DOVER NJ 07301/ (201) 628-9000 X777 (WORK)/ (201) 361-7180 (HOME) 

08046 LARRY E. ELLISON/ 19 HUNTINGTON LANE/ WILLINGBORO NJ 08046 

08108 JOHN H. DALY/ 210 HAZEL AVE./ WESTNUT NJ 08108 

08540 JA11ES C. EMERY/ INTERUNIVERSITY COMMUNICATIONS COUNCIL/ EDUCOM / P.O. BOX 364/ PRINCETON NJ 08540/ (609) 921-7575 

08753 ROBERT C. PERLE/ 1108 KUBY DRIVE/ TOMS RIVER NJ 037 53 

08854 JIM STEWART/ 195B PLEASANT VIEW ROAD/ PISCATAWAY NJ 08854/ (20 1) 382-5600 (WORK) 

09175 ATTN: SAM CALVIN/ COMPUTER EDUCATION/ DARMSTADT CAREER CENTER/ APO/ NEW YORK NY 09175 

10007 CHARI.ES KUllLMAN/ CRIMINAL JUSTICE AGENCY/ 305 BROADWAY - 5Trt FLOOR/ NEW YORK NY 10007/ (212) 577-0516 

10016 GENE A. DAVENPORT/ JOHN WILEY AND SONS/ 605 THIRD AVENUE/ NEW YORK NY 10016/ (212) 867-9800 X246 

10021 ROBERT L. SCHOENFELD/ ROCKEFELLER UNIVERSITY/ 1230 YORK AVE./ NEW YORK NY 10021/ (212) 360-1253 

10021 T. K. SHARPLESS/ INVESTIGATIVE CYTOLOGY/ MEMORIAL HOSPITAL/ 12 75 YORK AVE./ NEW YORK NY 10021/ (212) 794-6007 

10509 TIMOTHY P. ROBERTS/ KERN INSTRUMENTS INC./ GENEVA RD/ BREWSTER NY 10509/ (914) 279-^5095 

10583 THOflAS GIVENTER/ 1250 POST ROAD/ SCARSDALE NY 10583/ (914) 472-4035 

10804 GLEN R. J. MULES/ 263 BEECHHONT DRIVE/ NEW ROCHELLE NY 10804 

11418 HAROLD S. SCHECHTER/ 34-40 117 ST/ JAMAICA NY 11413/ (212) 849-8579 

11580 TIM WALSH/ 174 E. MAUJER STREET/ VALLEY STREAM NY 11580 

11771 JEFF KRAVITZ/ 69 ORCHARD ST. - APT. 3H/ OYSTER BAY NY 11771/ ( 516) 922-7757 

11794 GENE ROLLINS/ COMPUTER SCIENCE DEPT./ SUNY - STONY BROOK/ STONY BROOK NY 11794/ (516) 246-4383 

12206 SY GREENFIELD/ MIKROS SYSTEMS CORP/ 845 CENTRA!. AVE./ ALBANY NY 12206/ (513) 489-2561 

12301 SANDY WARSHAW/ 4B34/K1/ GENERAL ELECTRIC/ P.O. BOX 8/ SCHENECTADY NY 12301/ (518) 385-3192 

13088 R. A. STASIOR/ 18 FORESTER ROAD/ LIVERPOOL NY 13088/ (315) 456-7261 

13346 DEBORAH BUSCH/ COtlPUTER CENTER/ COLGATE UNIV./ HAMILTON NY 133 46/ (315) 824-1000 X484 

13901 QUENTIN F. STOUT/ DEPT. OF MATH SCIENCES/ SUNY - BINGHAMTON/ B INGHAMTON NY 13901/ (607) 798-2147 

13902 MARY DIEGERT/ MATHEMATICS DEPT./ BROOME COMMUNITY COLLEGE/ BIN ghAMTON NY 13902/ (607) 772-5000 
14063 GEORGE H. GOLDEN SR./ COMPUTER CENTER/ MAYTUM HAI.L/ SUNY FRFJ)0 NIA/ FREDONIA NY 14063/ (716) 673-3393 
1A221 GILBERT BERGLASS/ NANODATA CORP./ 2457 WEHRLE DR./ WILLIAMSVIL lE NY 14221 

14260 DUANE F. MARBLE/ DEPT. OF GEOGRAPHY/ SUNY-BUFFALO/ AMHERST NY 1426O/ ()l6) 636-2264 

14850 DAVID J. LEWIS/ MATHEMATICS DEPT./ ITHACA COLLEGE/ ITHACA NY 1 4350 

15021 R. E. STARCK/ OCEAN AIR INTERNATIONAL INC./ R.D. #1/ BURGETTST OWN PA 15021/ (412) 681-7533 

15108 TWI GRABOWSKI/ THE CHESTER ENGINEERS/ 845 FOURTH AVENUE/ CARAO POLIS PA 15108/ (412) 262-1035 

15213 JJIM TSEVDOS/ CARNEGIE-MELLON UNIV./ P.O. BOX 132/ PITTSBURGH PA 15213/ (412) 665-1036 

15260 ALAN M. LESGOLD/ LRDC COMPUTER FACILITY/ UNIV. OF PITTSBURGH/ 3939 O'HARA ST./ PITTSBURGH PA 15260 

15701 JOHN NOLD/ COMPUTER CENTER/ G6 STRIGHT HALL/ INDIANA UNIVERSITY OF PA./ INDIANA PA 15701/ (412) 357-4000 

15701 HOWARD E. TOMPKINS/ COMPUTER SCIENCE DEPT/ INDIANA UNIVERSITY OF PA/ INDIANA PA 15701/ (412) 357-2524 

16142 JIM PECK/ R.D. H - ORCHARD TERRACE/ NEW WILMINGTON PA 16142 

17019 E. R. BEAUREGARD/ R.D. 3 BOX 241/ DILLSBURG PA 17019/ (717) 79 0-2095 (WORK)/ (717) 766-1446 (HOME) 

17557 JOSEPH MEYER/ MS 103/ SPERRY - NEW HOLLAND/ 500 DILLER AVE./ N EW HOLLAND PA 17557/ (717) 354-1798 

17837 DANIEL C. HYDE/ COlffUTER SCIENCE PROGRAM/ BUCKNELL UNIVERSITY/ LEWISBURb PA 17837/ (717) 524-3743 

18042 ATTN: LAFAYETTE COLLEGE/ EASTON PA 18042 ; 

19083 T. L. (FRANK) PAPPAS/ 338 FRANCIS DRIVE/ HAVERTOWN PA 19083/ (2 15) 259-1325 

19117 FRED M. HOFKIN/ 8212 ASPEN WAY/ ELKINS PARK PA 19117/ (215) 88 6-4780 j 

19141 STEPHEN A. LONGO/ PHYSICS DEPT./ LA SALLE COLLEGE/ PHILADELPHIA PA 1914^/ (215) 951-1255 

19174 RICHARD D. HACKATHORN/ WHARTON SCHOOL - DEPT. OF DECISION SCI/ UNIV. OFj PENNSYLVANIA/ PHILADELPHIA PA 19174/ (215) 243-5149 

19311 ARTIE GREEN/ HEWLETT PACKARD/ ROUTE 41/ AVONDALE PA 19311/ (21 5) 268-22|81 

19335 WILLIAM C. HOPKINS/ 1101 BONDSVILLE ROAD/ DOWNINGTOVJN PA 19335/ (215) 2169-4486 

19401 DENNIS NICHOLSON/ 421 ALEXANDRA DR./ NORRISTOWN PA 19401/ (215 ) 539-82^3 

19403 JAMES A. MCGLINCHEY/ 332 WEYMOUTH RD. / PLYMOUTH TOVWSHIP/ NOR RISTO\W PA 19403 

19422 J. P. M. STOFBERG/ MS B/220M/ SPERRY UNIVAG/ P.O. BOX 500/ BLUE BELL PA 19422/ (215) 542-4011 

19422 PETER A. NAYLOR/ MS B/220M/ SPERRY UNIVAG/ P.O. BOX 500/ BLUE BELL PA 19422/ (215) 542-4011 

19424 WILLIAM L. HAFNER/ MAIL STOP 1B-220M/ SPERRY UHIVAC/ P.O. BOX 500/ BLUE BELL PA 19424/ (215) 542-4646 

19530 THOMAS PIRNOT/ MATH DEPT./ KURZTOra STATE COLLEGE/ KURZTOWN PA 19530 

19713 JAMES TRUEBLOOD/ PLATO PROJECT/ UNIV. OF DELAWARE/ 46 E. DELAWARE AVE./ NEWARK DE 19713 

19898 C. J. COTTON/ E. I. DUPONT DE NEMOURS CO./ 101 BEECH ST./ WILMINGTON DE 19898/ (302) 774-1372 

20007 MARTIN BUCHANAN/ SYSTEMS CONSULTANTS INC/ 1054 31ST STREET NW/ WASHINGTON DC 20007/ (202) 342-4000 

20008 BEARDSLEY RUML 2ND/ 3045 ORDWAY STREET NW/ WASHINGTON DC 20008/ (202) 244-3534 
20014 THOMAS A. MARCINIAK/ 8315 N. BROOK LN. ?903/ BETHESDA MD 20014/ (301) 654-7970 

20016 TIMOTHY SHAW/ EPA PROJECT OFFICE/ COMJIET/ 5185 MAGARTHUR BLVD. / WASHINGTON DC 20016/ (202) 244-1900 

20052 PETER BOCK/ DEPT OF ELEC ENGR & COMP SCI/ GEORGE VJASHINGTON UN IV. / 725 23RD ST NW/ VJASHINGTON DC 20052/ (202) 676-6083 

20229 STEVE O'KEEFE/ 7424/ U.S. CUSTOMS DATA CENTER/ 1301 CONSTITUTION AVE. N.W./ WASHINGTON DC 20229/ (202) 566-5447 

20234 JUSTIN C. WALKER/ SYSTEMS & SOFTWARE DIV./ A-264 BLDG. 225/ NATIONAL BUREAU OF STANDARDS/ WASHINGTON DC 20234/ (301) 921-3491 

20742 ANN MURPHY/ COMPUTER SCIENCE CENTER/ 2337 PROGRAM LIBRARY/ U F MARYLAND/ COLLEGE PARK !-lD 20742/ (301) 454-4262 

20760 F. T. BAKER/ IBM FEDERAL SYSTEMS DIV./ 13100 FREDERICK PIKE/ G AITHERSBURG MD 20750/ (301) 340-0111 

20771 FRANK E. MCGARRY/ GODDARD SPACE FLIGHT CENTER/ NASA/ CODE 582. 1/ GREENBELT MD 20771/ (301) 982-5048 

20854 ATTN: COMPUTER SCIENCE PRESS INC./ 9125 FALL RIVER ROAD/ POTOMAC MD 20854/ (301) 299-2040 

20854 HORNG JYH LIANG/ CONTROL DATA CORP./ 1151 SEVEN-LOCKS ROAD/ RO CKVILLE MD 20854/ (301) 340-3833 

20901 LEONARD BINSTOCK/ 820 LOXFORD TERRACE/ SILVER SPRING MD 20901/ (301) 593-3213/ (301) 496-3204 

20910 JOHN LATRASH/ 1001 CPRING ST. - ^ 1007/ SILVER SPRING MD 20910 / (301) 588-7894 

21014 BRUCE MAC ANASPIE/ 600 N. HICKORY AVE. - APT. 18/ BEL AIR MD 2 1014 

21114 ROBERT W. HARRIS/ COMMUNICATIONS AND SIGNAL PROCESSING/ MAR AS SOCIATES INC./ 1702 FALLSWAY DRIVE/ CROFTON MD 21114/ (301) 261-0780 

22027 CHARLES B. SHIPMAN JR./ 2205 SANDBURG ST./ DUNN LORING VA 2202 7 

22030 PETER N. ROTH/ 13146 MALTESE LANE/ FAIRFAX VA 22030 

22030 GENE SIMMONS/ 9514 FARMVIEW CT/ FAIRFAX VA 22030 

22032 ARtWLD SHORE/ 4607 BRIAR PATCH CT./ FAIRFAX VA 22032 

22044 MARK S. WATERBURY/ 2961 PATRICK HENRY DRIVE //201/ FALLS CHURCH VA 22044/ (703) 532-8119 

22101 W. ASHBY BOAZ/ BLDG.BXA/2/ TRW INC./ 7600 COLSUIRE DR./ MCLEAN VA 22101/ (703) 893-2000 

22209 LARRY DUBY/ 1724 N. QUINN ST. APT 305/ ARLINGTON VA 22209 

22209 FRANK LINDSAY/ BUNKER RAMO CORP/ 1500 WLSON BLVD. SUITE 400/ ARLINGTON VA 22209 

22209 DAVID J. MCKEE/ ADVANCED COMPUTER TECHNIQUES/ 1501 WILSON BLVD ./ ARLINGTON VA 22209/ (703) 524-8330 

22301 PHILIP GAUDETTE/ SOFTWARE RESOURCES/ P.O. BOX 2015/ ALEXANDRIA VA 22301/ (703) 548-2866 

22448 HARTMUT G. HUBER/ P.O. BOX 117/ DAHLGREN VA 22448/ (703) 663-8 656 

22901 LINWOOD FERGUSON/ 2605C HYDROLIC RD./ CHARLOTTESVILL VA 22901/ (804) 293-7816 

22903 R. LEONARD BROTO/ DAMACS/ THORNTON HALL/ UNIV. OF VIRGINIA/ CHARLOTTESVILL VA 22903/ (804) 924-7201 

23185 DOUGLAS DUNLOP/ 1502 CONWAY DRIVE - APT. 103/ WILLIAMSBURG VA 23185 
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ANH D. SA;ajl:,K'oO;j/ OFFICE OF COMFTLK; ACTIVIXlliS/ VIRGINIA COtUl 
RICKY W. BUTLER/ 132 WOODS ROAD/ NEWPORT NEWS VA 23601/ (804) 
DAVID A. HOUGH/ 223 BRYANT RD./ LYNCHBURG VA 24502/ (804) 237- 
WILLIAM L. MCLAIN III/ COriP SVCS/ GUILFORD COLLEGE/ 5800 W. FR 
STEVEN M. BELLOVIN/ DEFT. OF COMP. SCI./ U OF NORTH CAROLINA/ 
ROBERT L. CANNON/ DEPT. OF MATH. AND COMP. SCIENCE/ UNIV. OF S 
ATTENTION: JERRY W. SEGERS/ OFFICE OF COMPUTING SERVICES/ GEOR 
RICHARD LEBLANC/ SCHOOL OF INFO. AND COUP. SCI./ GEORGIA TECH/ 
R. GARY LEE/ DEPT. OF HATH./ 113 LOVE BUILDING/ FLORIDA STATE 
ANNA WATSON/ 3705 DELWOOD DRIVE/ PANAt-IA CITY FL 32407/ (904) 2 
MICHAEL D. WEINSTOCK/ 112 KNOLLWOOD WAY/ FT. WALTON FL 32548 
SCOrr CRUMPTON/ 11130 H.W. 9 PLACE/ GAINESVILLE FL 32601/ (904 
T. M. CAMBRON/ TR3/1/ HARRIS ESD/ P.O. BOX 37/ MELBOURNE FL 32 
ERICH R. KNOBIL/ PRODUCT DEVELOPMENT/ SYSTEMS ENGINEERI«JG LABS 
JEFFREY W. GRAHAM/ GRAHAM COMPUTER ENTERPRISES INC./ 3 OFFICE 
PEI HSIA/ 3300 O'HARA DR./ HUNTSVILLE AL 35801/ (205) 895-6088 
L. R. MARKER/ DEFENSE AND SPACE SYSTEMS/ TRW/ 7 702 GOVERNORS D 
ATTENTION: GORDON R. SHERMAjN/ COMPUTER CENTER/ 200 STOKELY MGM 
ROBERT M. SWEENEY/ ELLERS FANNING OAKLEY CHESTER & RIKE/ 722 F 
JAMES CRAIG ZIFX^LER/ 1455 LANCASTER DR./ MEMPHIS TN 38138 
JOE LERNER/ DEPT. OF PATHOLOGY/ UNIV. OF TENNESSEE/ 858 MADISO 
ATTN: DEPT. OF COMPUTER SCIENCE/ U OF MISSISSIPPI/ UNIVERSITY 
JAMES W. HOLT JR./ 7705 NORWOOD DR./ LOUISVILLE KY 40222/ (502 
JIM CAtlEKON/ DEPT. OF MATH SCIENCE/ DENISON UNIVERSITY/ GRANVI 
ROBERT RANSDELL/ 619 HARLEY DRIVE APT. 5/ COLUMBUS OH 43202 
RICHARD E. ADAMS/ 239 CHATHAM ROAD/ COLUMBUS OH 43214/ (614) 2 
DAVID PESEC/ 21030 MILLER AVENUE/ EUCLID OH 44119/ (216) 486-8 
R. L. PALASEK/ DEPT. OF APPLIED SCIENCES/ BOWLING GREEN STATE 
ATTN: BETTE BOLLING-LIBRARIAN/ TECHNICAL INFORMATION CTR-ELECT 
FRANCIS H. BEARDEN/ DATA SYSTEMS/ CINCINNATI ELECTRONICS CORP. 
R. WALDO ROTH/ COMPUTER SCIENCE DEPT/ TAYLOR UNIVERSITY/ UPLAN 
ANDREW S. PUCHRIK/ lUQ ANDRFA DR./ FLOYDS KNOBS IN 47119/ (50 
GEORGE A. R. SILVER/ DEPT. OF HISTORY/ EARLHAM COLLEGE/ RICHMO 
ANN BARDIN/ WRUBEL COMPUTING CENTER/ HPER BUILDING/ INDIANA UN 
FRANK PROSSER/ COMPUTER SCIENCE DEPT./ 101 LINDLEY HAI.L/ INDIA 
HOWARD CUNNINGHAM/ 914 NORTH 21ST STREET/ LAFAYETTE IN 47904/ 
SHAUN DEVLIN/ 6854 CEDARBROOK/ BIRMINGHAM MI 48010 
KURT METZGER/ 478 CLOVERDALE/ ANN ARBOR MI 48105 
DONALD D. REDDING/ MDSI/ 4251 PLYMOUTH ROAD/ ANN ARBOR MI 4810 
JAMES D. ROGAN/ COMSHARE INC./ P.O. BOX 1588/ ANN ARBOR MI 481 
E. SWEET/ COMPUTING CENTER/ UNIV. OF MICHIGAN-NORTH CAMPUS/ 10 
JOHN H. REMMERS/ DEPT. OF MATHEMATICS/ EASTERN MICHIGAN UNIV./ 
FREEMAN L. MOORE/ DEPT. OF COMPUTER SCIENCE/ 203-B PIERCE HALL 
ALLAN MOLUF/ 2317 KNOB HILL APT. 9/ OKEHOS MI 48864 
KENNETH KAPLAN/ MICROV/ARE SYSTEMS CORP/ P.O. BOX 954/ DES MOIN 
MICHAEL RODBY/ 322 DEVONSHIRE/ WATERLOO lA 50701/ (319) 233-57 
ATTN: SERIALS DEPT./ UNIVERSITY LIBRARIES/ UNIVERSITY OF IOWA/ 
MICHAEL WIMBLE/ 6026 UNDERWOOD AVE. S.W./ CEDAR RAPIDS lA 5240 
DAVID E. ANDERSON/ JOHNSON CONTROLS INC./ 507 E. MICHIGAN AVE. 
ALAN M. SHERKOW/ 1211 EAST SINGER CIR. APT. #4/ MILWAUKEE WI 5 
ATTN: FRIEDA S. COW/ ACADEMIC COMPUTING CENTER/ U OF WISCONSI 
MARK HORTON/ COMPUTER SCIENCE DEPT./ UNIV. OF WISCONSIN/ 1210 
WILL LELAND/ 445 N. LAKE ST./ MADISON WI 53715/ (608) 257-4035 
GREG MORRIS/ 1705 WILSON ST./ EAU CLAIRE WI 54701/ (715) 835-6 
GERALD F. UHLIG/ 3545 OVJASSO ST. APT. 110/ SHOREVIEW m 55112/ 
ATTN: INFORMATION SERVICE CENTER/ SPERRY-UNIVAC/ 2276 HIGH CRE 
DAVID GARDNER/ 1730 LARPENTEUR - APT. 3C/ ST. PAUL MN 55113/ ( 
GARY BECKWITH/ 2199 GLENRIDGE AVE./ ST. PAUL MN 55119/ (612) 8 
LEO J. SLECHTA/ DSD/ SPERRY UNIVAC/ BOX 3525 MS U1U25/ ST. PAU 
CLIFFORD GERSTENILABER/ DEFENSE SYSTEMS/ MNl 1-2120/ HONEYWELL/ 
CLARENCE LEHMAN/ 5926 GUMWOOD ROAD/ MOUND MN 55364/ (612) 472- 
ABDUL RASAQ BELLO/ P.O. BOX 8681/ MINNEAPOLIS MN 55408/ (612) 
MIKE KAMR,\n/ HONEYWELL AVIONICS/ 2600 RIDGWAY PKWY/ MINNEAPOLI 
STANLEY C. VESTAL/ MS 2340/ HONEYWELL INC./ 2600 RIDGWAY PKWY. 
THOM HOARD/ P.O. BOX 14413/ MINNEAPOLIS MN 55414/ (612) 376-62 
GENE H. OLSON/ 5149 ALDRICH AVE. S./ MINNEAP OLIS MN 55419/ (61 
WILLIAM J. LEE/ 7320 FIRST AVE. SO./ RICHFIELD MN 55423/(612) 
SUSAN A. PETERSON/ SOFTWARE DEVELOPMENT/ M.S. E-360/ DATA 100 
RICHARD SCHLOTFELDT/ 7330 GALLAGHER DR. - APT. 2 55/ EDINA MN 5 
RICHARD A. STONE/ DATA 100 CORP./ 7725 WASHINGTON AVE. SO./ MI 
CHRISTOPHER AMLEY/ SSRFC/ 25 BLEGEN HALL/ UNIV. OF MINNESOTA/ 
ATTN: SPECIAL INTERACTIVE COMPUTER LAB/ 143 SPACE SCIENCE CENT 
SCOTT S. BERTILSON/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR. 
PETER YAN-TEK HSU/ COMP. SCI. DEPT./ 114 LIND HALL/ U OF MINNE 
JOHN E. LIND/ 363 TERRITORIAL HALL/ UNIVERSITY OF MINNESOTA/ E 
DENNIS S. DELORME/ 1407 13TH AVENUE NE/ ROCHESTER MN 55901/ (5 
CLARENCE W. LYBARGER/ 3513 VILIJV ROAD N.W./ ROCHESTER MN 55901 
DANIEL NICHOLSON/ 2112 17TH AVE m/ ROCHESTER MN 55901/ (507) 
LEONARD SHAPIRO/ MATH DEPARTMENT/ NORTH DAKOTA STATE UNIV./ FA 
ROY TOUZEAU/ COMPUTER SCIENCE DEPT./ UNIV. OF MONTANA/ MISSOUL 
CHUI FAN LIU/ 1603 S. HIGHLAND AVE./ ARLINGTON HTS IL 60005 
HOWARD RUTIEZER/ 1101 ARBOR/ GLENVIEW IL 60025/ (312) 234-3400 
WILLIAM I. NOWICKI/ CSRL TECH/ B626/ NORTHWESTERN UNIV./ 2145 
RICHARD D. GEORGE/ ARGONNE NATIONAL LABORATORY/ 9700 S. CASS A 
JACK M. WIERDA/ DEPT. 7346/ WESTERN ELECTRIC COMPANY/ 4513 WES 
JA11ES R. KOCHANOWICZ/ DEDICATED SYSTEMS INC./ 180 N. MICHIGAN 
CHARLES MYERS/ DATALOCICS/ 325 W. HURON/ CHICAGO IL 60611/ (31 
DAVID J. ZOOK/ 1100 W. PRATT/ CHICAGO IL 60626 
MICHAEL FAY/ STELLE STATION/ CABERY IL 60919 

RALPH JOHNSON/ 1592 N. BROAD/ GALESBURG IL 61401/ (309) 342-30 
DONALD D. BURN/ 410 WEST ILLINOIS/ URBANA IL 61801/ (217) 367- 
HEIDI L. NEUBAUER/ COORDINATED SCIENCES LAB/ UNIV. OF ILLINOIS 
GREG STEPHEN/ DEPT. OF MATH. STUDIES/ S. ILLINOIS UNIV. AT EDW 
MIKE HARRIS/ APT. 4/ 309 WEST EDWARDS/ SPRINGFIELD IL 62704/ ( 
WILLIAM HOLMES/ DEPT. OF BIOCHEMISTRY/ WASHINGTON UNIV. MED. S 
JILL A. HOLTZ/ PROGRAMMING SCIENCES DEPT./ BLDG. 105 LEVEL 4/E 
STEPHEN J. WEINBERGER/ 8340 B. HILLCREST RD./ KANSAS CITY MO 6 
ARDEN WOOTTON/ 5904 N.W. LENOX AVE./ KANSAS CITY MO 64151/ (81 
BARBARA K. NORTH/ 1516 NICHOLS ST./ MANHATTAN KS 66502/ (913) 
FELIX DREHER/ COMPUTER SCIENCE/ PITTSBURG STATE UNIVERSITY/ PI 
FRED POSPESCHIL/ 3108 JACKSON ST./ BELLEVUE NE 68005/ (402) 29 
EARL N. CHRISTIANSEN/ BASCO COMPANY/ 9685 AMES/ OMAHA NE 68134 
CHARLES J. GIBBONS/ SUITE 8/ APPLIED COMMUNICATIONS INC./ 1084 
K. S. BHASKAR/ ACADEMIC COMPUTER SERVICES/ 225 NEBRASKA HALL/ 
D. F. COSTELLO/ ACADEMIC COMPUTING SERVICES/ UNIVERSITY OF NEB 
GEORGE NAGY/ DEPT. OF COMP. SCI./ 110 FERGUSON HALL/ U OF NEBR 
FRANK NUSSBAUM/ DEPT. OF MATH. SCIENCES/ LOYOLA UNIV./ 6525 N. 
HENRI A. LE FRIANT/ 8200 APRICOT ST./ NEW ORLEANS LA 70118/ (5 
RONALD P. MCRANEY/ STATION 1/ P.O. BOX 10097/ HOUMA LA 70360/ 
TIMOTHY M. SIMMONS/ HARDING COLLEGE/ BOX 1193 STATION A/ SEARC 
ABBAS RAFII/ 219 EECS DEPT./ UNIV. OF OKLAHOMA/ 202 W. 30YD/ N 
REFORD BOND/ ESSAY CORP./ 100 PARK AVE./ OKLAHOMA CITY OK 7310 
GARY HUCKABAY/ DEPT. OF MATHEMATICS/ CAMERON UNIV./ LAWTON OK 
C. BAILEY/ BAILEY AND ASSOCIATES/ 1144 S. ATLANTA/ TULSA OK 74 
ANTHONY BJERSTEDT/ ORAL ROBERTS UNIVERSITY/ BOX 1127/ TULSA OK 
PAUL D. JOHNSON/ 2009 WEDGEWOOD/ CARROLLTOH TX 75006/ (214) 24 
PORTIA ISAACSON/ THE MICRO STORE/ 634 S. CENTRAL EXPY./ RICHAR 
ROB SPRAY/ MS 420-160/ ROCKWELL INTERNATIONAL/ P.O. BOX 10462/ 
R. N. MILLER/ INTERNATIONAL COMPUTER PRODUCTS/ 2925 MERRELL RD 
MICHAEL SETTLE/ INTERNATIONAL COMPUTER PRODUCTS/ 2925 MERRELL 
KIM L. SHIVELEY/ 7 777 MANDERVILLE LANE APT. 221/ DALLAS TX 752 
LARRY T. NOVAK/ MS 348/ TEXAS INSTRUMENTS/ P.O. BOX 35486/ DAL 
JOE COINTMENT/ 7709 QUEENS GARDEN DR./ DALLAS TX 75248/ (214) 
JIM CLARKE/ P.O. BOX 517/ ARLINGTON TX 76010/ (817) 461-5429 
THOMAS E. SHIELDS/ SOFTWARE RESOURCES/ P.O. BOX 25210/ HOUSTON 
JAMES PATRICK MCGEE/ P.O. BOX 20223/ HOUSTON TX 77025/ (713) 6 
MIKE KERSEY/ 1850 W. MAIN Itl/ HOUSTON TX 77098/ (713) 526-8658 
BERT INGARFIELD/ ACTION COMPUTER SERVICES/ 2202 MUSTANG SPRING 
JERRY R. BROOKSHIRE/ 1201 HIGHWAY 30 - APT. 153/ COLLEGE STA. 
ANTHONY P. LUCIDO/ COMPUTING SCIENCES DEPT./ TEXAS A&M UNIV./ 
JON D. ROLAND/ MICRO MART/ 1015 NAVARRO/ SAN ANTONIO TX 78205/ 
JOHN SIGLE/ TRINITY UNIV./ P.O. BOX 237/ SAN ANTONIO TX 78284/ 



OMWl-ALTIi UHLVEKSil'Y/ 1015 FLOYD AVIC./ RICliriOiU) VA 23284/ (804) 770-6339 

596-7272/ (804) 827-2929 

5508 (HOME)/ (804) 384-5111 X2280 (WORK) 

IKNDLY AVE./ GREENSBORO NC 27410/ (919) 292-5511 X139 

CHAPEL HILL NC 27514/ (919) 933-7240 

0. CAROLINA/ COLUMBIA SC 29208 

GIA INSTITUTE OF TECHNOLOGY/ ATLANTA GA 30332/ (404) 894-4676 

ATI.ANTA GA 30332/ (404) 894-2592 
U/ TAI.LAHASSEE FL 32306/ (904) 644-4419 
34-2507 

) 375-7952 

901/ (305) 727-4629 

./ 6901 WEST SUNRISE BLVD./ FT. LAUDERDALE FL 33313/ (305) 587-2900 

PARK CIR. - SUITE 106/ BIRt'llNGHAM AL 35223/ (205) 870-7267 

R. WEST/ HUNTSVILLE AL 35805/ (205) 337-3950 

T. CENTER/ U OF TENNESSEE/ KNOXVILLE TN 37916/ (615) 974-6721 

ALLS BUILDING/ MEMPHIS TN 38103/ (901) 526-7321 

N AVE./ MEMPHIS TN 38163/ (901) 528-6320 

MS 38677 

) 425-6729 

LLE OH 43023/ (614) 587-0810 X582 

67-8068 

070 

UNIV./ 901 RYE BEACH ROAD/ HURON OH 44839 

RONICS/ CINCINNATI MILACRON INC./ LEBAI^ION OH 45036/ (513) 494-5320 

/ 2630 GLENDALE-MILFORD ROAD/ CINCINNATI OH 45241/ (513) 563-6000 

D IN 46989/ (317) 998-2751 X269 

2) 582-4397 

ND IN 47374/ (317) 962-6561 

IV. / BLOOMINGTON IN 47401/ (812) 337-1911 

NA UNIVERSITY/ BLOOMINGTON IN 47401 

(317) 447-6403 

5/ (313) 995-6118 
06/ (313) 994-4800 
75 BEAL AVE./ ANN ARBOR MI 48109 
YPSILANTI MI 48197/ (313) 487-1290 
/ CENTRAL MICHIGAN UNIV./ MT. PLEAS.ANT MI 48859/ (517) 774-3922 

ES lA 50304/ (515) 265-6121 
96 

IOWA CITY lA 52242 
4/ (319) 396-5641 

/ MILWAUKEE WI 53201/ (414) 276-9200 
3212/ (414) 332-9533 

N/ 1210 W. DAYTON ST./ MADISON WI 53706/ (608) 262-2055 
W. DAYTON ST./ !>IADIS0N WI 53706/ (608) 262-1079/ (608) 238-1366 

324 

(612) 483-9714 
ST DRIVE/ ROSEVILLE m 55113 
612) 646-5479 
53-5235 

L MN 55165/ (612) 456-2743 

600 SECOND ST. N.E./ HOPKINS Mtl 55343/ (612) 542-4940 
1405 

330-4106 

S UN 55413/ (612) 373-5328 
/ MINNEAPOLIS MN 55413/ (612) 378-5046 
90 
2) 824-9108 

866-6284 
CORP./ 7725 WASHINGTON AVE S./ MINNEAPOLIS UN 55432/ (612) 941-6500 X437 
5435/ (612) 831-6403 

NNEAPOLIS MN 55435/ (612) 941-6500 X479 
WEST BANK/ MINNEAPOLIS MN 55455/ (612) 373-9917 

ER/ UNIV. OF MINNESOTA/ EAST BANK/ MINNEAPOLIS t-IN 55455/ (612) 373-5768 

/ UNIV. OF MINNESOTA/ MINNEAPOLIS MN 55455/ (612) 376-5262 (WORK)/ (612) 331-2464 (HOME) 
SOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 376-4590 
AST BANK/ MINNEAPOLIS MN 55455/ (612) 373-6545 
07) 289-8495 
/ (507) 289-0053 

289-1780 (HOME)/ (507) 286-5921 (WORK) 
RGO ND 58102/ (701) 237-8171 
A m 59812/ (406) 243-2383 (WORK)/ (406) 549-8064 (HOME) 

(WORK)/ (312) 724-7731 (HOME) 
SHERIDAN RD/ EVANSTOH IL 60201/ (312) 492-5248 
VENUE/ ARGONNE IL 60439 

TERN AVE./ LISLE IL 60532/ (312) 983-3439 
AVE./ CHICAGO IL 60601/ (312) 372-4222 
2) 266-4444 



98 
5362 

- URBANA/ URBANA IL 61801/ (217) 333-4796 WORK 
ARDSVILLE/ EDWARDSVILLE IL 62026 
217) 789-7669 (HOME)/ (217) 782-0014 (WORK) 

CHOOL/ 660 S. EUCLID AVE./ ST. LOUIS MO 63110/ (314) 454-3622 
-6/ MCDONNELL DOUGLAS CORP./ P.O. BOX 516/ ST. LOUIS MO 63166 
4138/ (816) 333-9311 
6) 741-5822 

532-6350 WORK/ (913) 537-7818 HOME 
TTSBURG KS 66762/ (316) 232-7000 X425 
1-0795 
/ (402) 572-8911 

4 OLD MILL ROAD/ OMAHA NE 68154/ (402) 330-3732 

UNIV. OF NEBRASKA - LINCOLN/ LINCOLN NE 68503/ (402) 472-3701 

RASKA-LINCOLN/ 3835 HOLDREGE/ LINCOLN NE 68583 

ASKA/ LINCOLN NE 68588/ (402) 472-3200/ (402) 472-2402 

SHERIDAN/ CHICAGO IL 69626 
04) 865-1023 
(504) 868-0453 
Y AR 72143/ (501) 268-6753 
ORMAN OK 73019/ (405) 325-4721 
2 

73501 
104/ (918) 936-0596 

74171/ (918) 492-2011 
5-7904 
DSON TX 75080/ (214) 231-1096 

DALLAS TX 75207/ (214) 996-2255 
./ DALLAS TX 75229/ (214) 350-6951 
RD./ DALLAS TX 75229 
31 

LAS TX 75235/ (214) 238-6904 
387-0468 

TX 77005/ (713) 521-0366 
68-6232 

5 DRIVE/ MISSOURI CITY TX 77459/ (713) 437-5197 
TX 77840/ (713) 693-2938 

COLLEGE STA. TX 77843/ (713) 845-5531 
(512) 222-1427 
(512) 736-7236 
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94040 
94043 
94086 
94086 
94086 
94086 
94087 
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95014 
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95014 
95014 

95014 
95014 
95030 
95030 
95050 
95050 
95051 



JAMES L. PETERSON/ DEPT OF COllPUTER SCIENCES/ PAINTER HALL/ UN 
DAVID M. PHILLIPS/ 6922 THOMAS SPRINGS RD./ AUSTIN TX 78736/ ( 
ED NAYLOR/ P.O. BOX 15103/ AUSTIN TX 78761/ (512) 451-0342 
DAVID N. GRAY/ MS 2188/ TEXAS INSTRUMENTS/ P.O. BOX 2909/ AUST 
EDWARD C. HUMPHREY/ M.S. 2201/ TEXAS INSTRUMENTS INC./ P.O. BO 
LYTLE JOHNSON/ 8951 W. 46TH PLACE/ WHEAT RIDGE CO 80033 
GERHARDT C. CLEMENTSON/ DEPT. OF COMP. AND MGMT SCIENCE/ METRO 
HOWARD L. TURETZKY/ HYDRA/ 1575 IVANHOE ST./ DENVER CO 80220/ 
DAVID PICKENS/ DEPT. 50J/ BLDG. 023/ IBM CORP./ P.O. BOX 1900/ 
ZHAHAI STEWART/ P.O. BOX 1637/ BOULDER CO 80306/ (303) 443-727 
H. W. EGDORF/ P.O. BOX 226/ GOLDEN CO 80401/ (303) 234-3994 (W 
HERB RUBENSTEIN/ 1036 6TH STREET/ GOLDEN CO 80401/ (303) 278-3 
PATRICIA R. MOHILNER/ DEPT. OF COMPUTER SCIENCE/ COLORADO STAT 
GREG BOURQUE/ HEWLETT PACKARD/ P.O. BOX 2197/ COLORADO SPRIN C 
ED HIRAHARA/ 11207 MUSKET ST./ BOISE ID 83704/ (208) 376-6000 
JOHN A. BRIGGS/ 837 EAST 6775 SOUTH/ MIDVALE UT 84047/ (801) 2 
RICHARD W. KREUTZER/ 644 ELIZABETH ST./ SALT LAKE CITY UT 8410 
W. F. HAYGOOD/ COMPUTER SERVICES CO./ 7822 OAKLEOGE ROAD/ SALT 
S. JOHNSON/ ECS/ MARIOPA CO. COMM. COLLEGE/ P.O. BOX 13349/ PH 
ALLEN BERGLUND/ MS K-28/ P.O. BOX 6000/ PHOENIX AZ 85005/ (602 
MICHAEL A. HOUGHTALING/ UNIV. OF ARIZONA/ 3401 N. COLUMBUS APT 
STEVE JAY/ COMPUTER CENTER/ UNIV. OF ARIZONA/ TUCSON AZ 85721/ 
FULTON WRIGHT JR./ COMPUTER SERVICES/ YAVAPAI COLLEGE/ PRESCOT 
REESA ABRAMS/ FALCON RESEARCH AND DEVELOPMENT/ 2350 ALAMO S.E. 
STEPHEN C. WOOD/ MICROSOFT/ 819 TWO PARK CENTRAL TOWER/ ALBUQU 
ROBERT T. JOHNSON/ C-11 MAIL STOP 296/ LOS ALAMOS SCIENTIFIC L 
WILLIAM M. SEIFERT/ MS 532/ LASL/ P.O. BOX 1663/ LOS ALAMOS NM 
T. A. NARTKER/ ITEPT. OF COMPUTER SCIENCE/ NEW MEXICO TECH/ SOC 
JOSEPH EINWECK/ P.O. BOX 3824/ LAS CRUCES NM 88003/ (505) 523- 
ATTN: PROGRAJ-IMING ADVISOR/ SOUTHERN NEVADA COMPUTING FACILITY/ 
DARRYL KUHMS/ 1590 HILLSIDE DR./ RENO NV 89503 
ATTN: PROGRAMMING ADVISOR/ UNS COMPUTING CENTER/ 22 WR/ U OF 
E. MAURICE BESSLEY/ DEPT. OF MATHEMATICS/ 227 SEM/ UNIV. OF NE 
LAUREN WEINSTEIN/ 12320 TEXAS AVE. #12/ LOS ANGELES CA 90025/ 
R. F. TAYLOR/ 1509 SARGENT PLACE/ LOS ANGELES CA 90026/ (213) 
MELVIN L. NORELL/ PROGRAMMA CONSULTANTS/ P.O. BOX 70127/ LOS A 
LEE D. AURICH/ 5650 SUMNER WAY # 116/ CULVER CITY CA 90230/ (2 
DAVID INTERSIMONE/ SOFTWARE ENGINEERING SECTION/ TRW - CS&S/ 1 
CARSON GERl-lAN/ 9615 WALNUT ST./ BELLFLOWER CA 90706/ (714) 871 
CHARLES L. LAWSON/ JET PROPULSION LABORATORY/ MS 125/128/ CALI 
W. 0. PAINE/ MS 83-101/ JET PROPULSION LAB./ 4800 OAK GROVE DR 
ATTN: LIBRARY/ BURROUGHS CORP./ 460 SIERRA MADRE VILLA/ PASADE 
KARL FRYXELL/ DIVISION OF BIOLOGY/ 216-76/ CALIFORNIA INST. OF 
TOM SANDERSON/ MICROSYSTEMS DIVISION/ MAIL STOP 63-02/ PERTEC 
RUSSEL J. ABBOTT/ DEPT. OF COMPUTER SCIENCE/ CALIF. STATE UNIV 
ELIZABETH IBARRA/ 432 E. WILBUR RD #104/ THOUSAND OAKS CA 9136 
TONY NOE/ COMPUTING/ HARVEY MUDD COLLEGE/ CLAREMONT CA 91711/ 
JUDY HERRON/ MT. SAN ANTONIO COLLEGE/ 1100 NORTH GRAND AVENUE/ 
DAVID H. BROWN/ 5709 ABALONE PLACE/ LA JOLIA CA 92037/ (714) 2 
ATTN: STUDENT COMPUTING COOP/ APIS DEPT/ C-014/ UNIV. OF CALIF 
RICHARD KAUFMAN/ INSTITUTE FOR INFO. SYSTEMS/ C-021/ UNIV. OF 
KEITH ALLAN SHILLINGTON/ INSTITUTE FOR INFORMATION SYSTEMS/ UC 
TOM KNOCHE/ 2061 REED/ SAN DIEGO CA 92109/ (714) 270-7099 
JOSEPH W. SMITH/ NCR/ 16550 WEST BERNARDO DR./ SAN DIEGO CA 92 
W. E. CLARK/ DEPT. 244/ P.O. BOX 80158/ SAN DIEGO CA 92138/ (7 
SCOTT T. DAVIDSON/ LOGICOH/ P.O. BOX 80158/ 4010 SORRENTO VALL 
A. PAUL CROONENBERGHS/ 74415 CACTUS DRIVE/ TWENTY-9 PALMS CA 9 
DAVID H. WELCH/ P.O. BOX 207/ RIVERSIDE CA 92501/ (714) 338-46 
BRUCE YALE/ 15840 SADDLEBACK RD./ RIVERSIDE CA 92506/ (714) 78 
WILLIAM J. ARTHUR/ 26016 VIEW POINT DRIVE FAST/ CAPISTRANO BCH 
K. W. BIXBY/ BECKMAN INSTRUMENTS/ 2500 HARBOR BLVD./ FULLERTON 
TOM SNYDER/ BLDG 606/M136/ HUGHES AIRCRAFT CO./ P.O. BOX 3310/ 
JAMES H. WELLS/ BLDG. 606 - MS K232/ HUGHES AIRCRAFT/ P.O. BOX 
ROGER SIPPL/ 1806 TOYOK LANE/ NEWPORT BEACH CA 92660/ (714) 64 
DAVID A. BEERS/ 1050 CABRILLO PARK DR. APT. 34A/ SANTA ANA CA 
RONALD C. WHITES/ 1090 CABRILLO PARK DR. - APT. 64A/ SANTA ANA 
DONALD V. MYIIRA/ 14142 GERSHOM PL/ SANTA ANA CA 92705/ (714) 5 
ERIC OLSEN/ MINICOMPUTER OPERATIONS/ SPERRY UNIVAC/ 2722 MICHE 
SHERRY L. CAJiEROU/ PERTEC COMPUTER CORP./ 17112 ARMSTRONG/ IRV 
RICHARD P. SPRAGUE/ PERTEC COMPUTER CORPORATION/ 17112 ARMSTRO 
DENNIS J. MAINE/ ICS DEPT./ UNIV. OF CALIF. - IRVINE/ IRVINE C 
JAMES D. LETZ/ GENERAL AUTOMATION INC./ 1055 S. EAST STREET/ A 
MARK JUNGWIRTH/ 5408 E. HOLLY RIOGE DR./ CAMARILLO CA 93010 
ANDY HARRINGTON/ 218 SAN NAPOLI/ GOLETA CA 93017/ (805) 968-69 
RON JEFFRIES/ 651 ARDMORE/ GOLETA CA 93017/ (805) 964-8964 
CLEMENT L. DICKEY/ COMPUTER CENTER/ CALIF. POLYTECH. STATE UNI 
RICK GILLIGAN/ COMPUTER CENTER/ CALIF. POLYTECH. STATE UNIV./ 
DAVID W. SALLUME/ 945 VIA FARGO/ SANTA MARIA CA 93454/ (805) 9 
ROGER CREAMER/ CTB/ MCGRAW HILL/ DEL MONTE RESEARCH PARK/ MONT 
LES VOGEL/ 366 VAN BUREN - APT. A/ MONTEREY CA 93940/ (408) 37 
JOHN R. BOGAN/ 1201 VANCOUVER AVE./ BURLINGAME CA 94010/ (415) 
JAMES B. ONEY/ 1240 MONTE VERDE COURT/ LOS ALTOS CA 94022/ (41 
DAVID F. FRICK/ 920 PEGGY LANE/ MENLO PARK CA 94025/ (415) 329 
BRUCE J. EDMUNDSON/ 575 S. RENGSTORFF AVE. - APT. 62/ MOUNTAIN 
IRVINE L. MCKNIGHT/ 505 CYPRESS PT. DR. APT. 52/ MOUNTAIN VIEW 
BYRON HALE/ 813 FARLEY ST./ MT. VIEW CA 94043 

ATTN: UNBOUNDED COMPUTING/ 667 TOYON AVE./ SUNNYVALE CA 94086/ 
STEVE MCFERRIN/ BENDIX FIELD ENGINEERING/ 155B MOFFETT PARK DR 
JIM MERRITT/ 655 SO. FAIROAKS AVENUE APT L-216/ SUNNYVALE CA 9 
RONALD H. PERROTT/ INSTITUTE FOR ADVANCED COMPUTATION/ P.O. BO 
R. STEVEN GLANVILLE/ 1531 SANDPIPER CT./ SUNNYVALE CA 94087/ ( 
CHARLES T. LEIS/ 560 MIDDLEBURY DR./ SUNNYVALE CA 94087 
ROBERT J. RAiCER/ PACIFIC GAS 6. ELECTRIC CO./ 1 POST ST. - NO. 
LYALL MORRILL/ 705 NOE STREET/ SAN FRANCISCO CA 94114/ (415) 6 
WILLIAM R. LLOYD/ 3190 CLAY STREET/ SAN FRANCISCO CA 94115/ (4 
ROLAND L. LEE/ 645 35TH AVE/ SAN FRANCISCO CA 94121 
SHARLEEN WONG/ 151 MADISON STREET/ SAN FRANCISCO CA 94134/ (41 
ATTN: LIBRARY - COPY 2/ BIN 82/ STANFORD LINEAR ACCELERATOR CT 
JOHN BANNING/ MAIL DROP 88/ STANFORD LINEAR ACCELERATOR CENTER 
SASSAN HAZEGHI/ P.O. BOX 4526/ STANFORD CA 94305/ (415) 854-33 
SUSAN S. OWICKI/ DIGITAL SYSTEMS LABORATORY/ STANFORD UNIVERSI 
CHRIS K. PHILLIPS/ P.O. BOX A-C/ STANFORD CA 94305/ (415) 493- 
SCOTT WAKEFIELD/ DIGITAL SYSTEMS LABORATORY/ STANFORD UNIV./ S 
TIMOTHY H. JACKINS/ 585 ASHTON AVE./ PALO ALTO CA 94306/ (415) 
PING K. LIAO/ 2499 CONSTELLATION DR./ HAYWARD CA 94545/ (415) 
C. W. CHILDERS/ P.O. BOX 761/ LIVERMORE CA 94550/ (415) 422-27 
DOUGLAS N. JOHNSON/ LONGS DRUG STORES/ 141 N. CIVIC DRIVE/ WAL 
JAMES A. STARK/ 485 34TH STREET/ OAKLAND CA 94609/ (415) 658-2 
FRANK W. OECHSLI/ CHILD HEALTH & DEVELOPMENT/ UIIIV. OF CAI.IF. 
DOUG FORSTER/ 1133 OAKLAND AVENUE/ PIEDMONT CA 94611 
MICHAEL L. SIEMON/ 6013 HARUOOD AVE./ OAKLAND CA 94613 
ERIC WOGSBERG/ COMPUTER TECHNOLOGY/ 6043 LAWTOH AVE./ OAKLAND 
RICHARD W. HAMILTON/ 1249 U. BROADWAY/ EUGENE OR 94702 
JOHN MEDCALF/ CONCEPT SOFT-JARE/ 1342 SAN ANTONIO AVE/ BERKELEY 
SUSAN L. GRAHA.M/ COMP. SCI. DIVISION-EECS/ 511 EVANS lULL/ U 
MICHAEL C. ARMSTRONG/ BADGER METER INC./ 150 E. STANDARD AVE./ 
ROBERT M. BAER/ 379 COUNTRYVIEW DRIVE/ MILL VALLEY CA 94941 
JOHN WALKER/ MARINCHIP SYSTEMS/ 16 ST. JUDE ROAD/ MILL VALLEY 
BRUCE WOLFE/ 71 SUNSHINE AVE./ SAUSALITO CA 94965/ (415) 332-6 
DAVID J. BELL/ MICRO-SYSTEMS ENGINEERING/ 609 CRAIG AVE./ CAMP 
ATTN: CUPERTINO LIBRARY/ HEVrt^RTT PACKARD/ 11000 WOLFE ROAD/ CU 
MICIL\EL J. COOK/ 1658 S. STELLING/ CUPERTINO CA 95014 
BILL FINCH/ DATA TERMINALS DIV/ HEWLETT PACKARD CO/ 19400 HOME 
DAVID F. OHL/ P.O. 'BOX 257/ CUPERTINO CA 95014/ (408) 926-9803 

RICHARD PALCHIK/ TYMNET/ 10261 BUBB ROAD/ CUPERTINO CA 95014/ (408) 446-6652 

JIM SCHULTZ/ HEWLETT PACKARD/ 1 1000 WOLFE RD - 42U/ CUPERTINO CA 95014/ (408) 257-7000 

DON GILMORE/ GILMORE ASSOCIATES/ P.O. BOX 1723/ LOS GATOS CA 9 5030/ (408) 395-4300 

C. DUDLEY WARNER/ 16345 LOS GATOS BLVD. - // 41/ LOS GATOS CA 9 5030 

JOHN CARTER SR./ 3796 PINEWOOD PLACE/ SANTA CLARA CA 95050/ (4 08) 988-2629 

BRUCE SHERRY/ 1601 WARBURTON AVE. - APT. 12/ SANTA CLARA CA 95 050 

RONALD L. DANIELSON/ DEPARTMENT OF EECS/ UNIVERSITY OF SANTA C LARA/ SANTA CLARA CA 95051/ (408) 984-4181 



IV. OF TEXAS - AUSTIN/ AUSTIN TX 78712/ (512) 471-4353 
512) 471-7202 

IN TX 78769/ (512) 258-7406 

X 2909/ AUSTIN TX 78769/ (512) 258-7289 

POLITAN STATE COLLEGE/ 1006 UTH STREET BOX 13/ DENVER CO 80204/ (303) 629-3122 
(303) 333-2892 

BOULDER CO 80302/ (303) 447-5844 
9 

ORK) 

469/ (303) 458-5900 X202 (WORK) 
E UNIV./ FORT COLLINS CO 80523/ (303) 491-7137 
80901/ (303) 598-1900 
X2574/ OR X3989 
92-8000 
2/ (801) 583-5202/ (801) 486-3351 

LAKE CITY UT 84121 
OENIX AZ 85002 
) 249-7466 
. 17-B/ TUCSON AZ 85712/ (602) 884-4239 

(602) 884-2239 
T AZ 86301/ (602) 778-1990 

- #200/ ALBUQUERQUE NM 87106/ (505) 843-6101 
ERQUE NM 87108/ (505) 256-3600 
ABORATORY/ P.O. BOX 1663/ LOS ALAMOS NM 87545/ (505) 667-5014 

87545 
ORRO NM 87801/ (505) 835-5126 
5377 

UNIV. OF NEVADA - LAS VEGAS/ 4505 MARYLAND PARKWAY/ LAS VEGAS NV 89154/ (702) 739-3557 

EVADA/ BOX 9068/ RENO NV 89507/ (702) 784-4008 

VADA-RENO/ RENO NV 89557/ (702) 784-6773 

(213) 826-5766 

488-0288 

NGELES CA 90070/ (213) 243-0810 

13) 649-4404 

2911 SIMMS AVE./ HAWTHORNE CA 90250/ (213) 536-4286 
-3232 X2068 

FORNIA INSTITUTE OF TECHNOLOGY/ 4800 OAK GROVE DR./ PASADENA CA 91103/ (213) 354-4321 
./ PASADENA CA 91103/ (213) 354-4284 
NA CA 91109/ (213) 351-6551 X505 

TECH./ PASADENA CA 91125/ (213) 795-6811 X2818 
COMPUTER CORP./ 20630 NORDHOFF/ CHATSWORTH CA 91311/ (213) 998-1800 X256 

NORTHRIDGE/ 13111 NORDHOFF STREET/ NORTHRIDGE CA 91330/ (213) 385-3398 
0/ (805) 488-4425 
(714) 626-8511 X2897 

WALNUT CA 91789/ (714) 598-2811 
93-6072 

ORNIA - SAN DIEGO/ P.O. BOX 109/ LA JOLLA CA 92093/ (714) 452-4723 
CALIFORNIA - SAN DIEGO/ LA JOLLA CA 92093/ (714) 452-4723 
SD MAILCODE C-021/ LA JOLLA CA 92093/ (714) 452-4723 

127/ (714) 485-2364 

14) 455-1330 X348 

EY B/ SAN DIEGO CA 92138/ (714) 455-1330 X348 
2277 
36 
0-7624 

CA 92624/ (714) 493-5453 

CA 92634/ (714) 871-4848 X1393 

FULLERTON CA 92634 

3310/ FULLERTON CA 92634 
2-8977 
92701/ (714) 543-6075 

CA 92701/ (714) 974-0800 
44-5314 

LSON DRIVE/ IRVINE CA 92713/ (714) 833-2400 
INE CA 92714/ (714) 836-4592 
NG AVE./ SANTA ANA CA 92714/ (714) 540-8340 
A 92717/ (714) 833-5233 
NAHEIM CA 92805/ (714) 778-4800 X261 

34 (HOME) 

v./ SANLUIS OBISPO CA 93407/ (805) 546-2004 

SANLUIS OBISPO CA 93407/ (805) 546-2004 

37-4541 

EREY CA 93940/ (408) 649-3400 

5-4245 

343-5452 
5) 961-8825 
-1013 

VIEW CA 94040 

CA 94040/ (415) 967-0414 

(408) 247-3182 
./ SUNNYVALE CA 94086 
4086/ (408) 733-6112 

X 9071/ SUNNYVALE CA 94086/ (408) 735-0635 X273 
408) 241-6294 

2200/ SAN FRANCISCO CA 94104 
47-8518 

15) 556-2235 

5) 586-2467 

R./ P.O. BOX 4349/ STANFORD CA 94305 

/ P.O.BOX 4349/ STANFORD CA 94305/ (415) 854-3300 X2802 (OFFICE)/ (415) 325-9226 (HOUF.) 

00 X2359 

TY/ STANFORD CA 94305 

2977/ (408) 988-1450 

TAN FORD CA 94305 

494-0467 
494-3942 X577 (WORK) 
79 

NUT CREEK CA 94598/ (415) 937-1174 
566 
- BERKELEY/ 3867 HOWE ST./ OAKLAND CA 94611/ (415) 655-7947 



CA 94618/ (415) 653-4844 

CA 94707/ (415) 526-4035 
F CALIFORNIA/ BERKELEY CA 94720/ (415) 642-2059/ 642-1024 (MESSAGES) 
RICHMOND CA 94804/ (415) 233-3220 

CA 94941/ (415) 333-1545 

242 

BELL CA 95008/ (408) 379-5841/ (408) 379-2498 

PERTINO CA 95014 

STEAD PJ)/ CUPERTINO CA 95014/ (403) 257-7000 
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JERRY DI MASSA/ T.E.D./ SIEMENS CORP./ 1333 LAWRENCE EXP. - SUITE 400/ SANTA CLARA CA 95031/ (408) 984-8310 

CECIL A. MOORE/ INTEL CORP./ 3065 BOWERS AVENUE/ SANTA aARA C A 95051/ (408) 987-8080 

JOHN NAGLE/ INFORMATION SYSTEMS DESIGN/ 3205 CORONADO DR./ SAN TA CLARA CA 95051/ (408) 249-3100 

PAUL J. PANTANO/ TED/ SIEMENS CORP./ 1333 LAITOENCE EXP. - SUIT E 400/ SANTA CLARA CA 95051/ (408) 984-8810 

ED SCHOELL/ DEPT. NSAU/ NATIONAL SEMICONDUCTOR/ SANTA aARA CA 95051 

MICHAEL K. STAUFFER/ SEARLE ULTRASOUND/ 2270 MARTIN AVE./ SANT A CLARA CA 95051/ (408) 984-2900 

MIKE TRAVIS/ SOFTWARE SUPPORT/ INTERDATA INC/ 3080 OLCOTT ST. " SUITE 125A/ SANTA CLARA CA 95051/ (408) 249-5540 

ALAN M. SCHLENGER/ COMPUTER CENTER/ UNIV. OF CALIF. - SANTA CR "Z/ SANTA CRUZ CA 95064 

HOWARD S. COLEY JR./ 18950 MCFARLAND AVE./ SARATOGA CA 95070/ ^^^^^ 374-5363 

MEL R. FISHER/ BUSINESS DEPT./ CALVARY COMMUNITY CHURCH/ 1175 

ALAN DELWICHE/ LELAND HIGH SCHOOL/ 6677 CAI1DEN AVE./ SAN JOSE 

JOHN H. KILFOIL/ 1777 TOPEKA AVE./ SAN JOSE CA 95126 



HILLSDALE AVE./ SAN JOSE CA 95118/ (408) 269-8331 
CA 95120/ (408) 993-6290 



GENE H. PRIESTMAN/ 1155-29 WEYBURN LANE/ SAN JOSE CA 95129/ (4 



8) 255-3939 



DAMON BLOM/ 72 SANDBURG DR./ SACRAMENTO CA 95819/ (916) 455-45 '' J^^^^^^ ^^^J^J. cl 95926/^(5 it! 895-6442 



SniNG-KIN PUN/ DEPT OF COMPUTER SCIENCE/ CALIFORNL\ STATE UHIV * , „. „„, ,„.,. „„. ,,,, 

ATTN: CHICO PROJECT - CDC/ SCHOOL OF APPLIED SCIENCES/ CALIFORNIA STATE UNIV./ CHICO CA 95929/ (916) 895-6713 

ORLANDO S. MADRIGAL/ DEPT. OF COM?. SCI./ CALIFORNIA ST. UNIV. " CHICO/ CHICO CA 95929/ (916) 895-6442 

JOHN COUSINS/ 2435 S.W. ECOLE - APT. 67/ BEAVERTOH OR 97005 

DON TERWILLIGER/ 9100 S.W. PARKVIH^ LOOP/ BEAVERTOH OR 97005/ (503) 644-1933 

KEN LESSEY/ 50 V7EST ST./ ST. HELENS OR 97051/ (503) 397-1305 

DON HARVEY/ P.O. BOX 367/ WILSONVILLE OR 97070 

ROY CARLSON/ (50-454)/ TEKTRONIX/ P.O. BOX 500/ BEAVERTON OR 9 7077/ (503) 644-0161 X5616 

BOB DIETRICH/ MS 60-45C/ TEKTRONIX INC./ P.O. BOX 500/ BEAVERTON OR 97077/ (503) 682-3411 X2398 

MARVIN WHITE/ MS 94-344/ TEKTRONIX INC./ P.O. BOX 500/ BEAyERT ON OR 97077 

JOHN L. RUTIS/ RT 2 BOX 7H/ BANKS OR 97106 

BRIAN HANSEN/ 2426 N.E. 57TH AVE. APT #3/ PORTLAND OR 97213/ ( 503) 284-3537 

JAMES N. O'BRIEN/ 13900 SCIENCE PARK DR/ PORTLAND OR 97229/ (5 03) 641-4141 

DAVID SKINNER/ ALPHA OMF/!A COMPUTER SYSTEMS/ P.O. BOX 392/ COR VALLIS OR 97330/ (503) 754-1911 

CHIP WEEMS/ DEPT. OF COMPUTER SCIENCE/ OREGON STATE UNIV./ COR VALLIS OR 97331/ (503) 754-3273 

ATTN: NORTHWEST MICROCOMPUTER SYSTEMS/ 121 E. IITH ST./ EUGENE OR 97401/ (503) 485-0626 

ATTN: SUSAN BOOTE - DOCUMENTS ROOM/ COttPUTER CENTER/ UNIV. OF OREGON/ EUGENE OR 97403/ (503) 686-4406 

R. BUSH/ NORTHWEST MICRO/ 219 FITZPATRICK BLDG./ COOSBAY OR 97 ^20/ (503) 269-2432 

WILLIAM J. MARSHALL/ 11626 lUTH AVE. N.E./ KIRKLAND WA 98033/ (206) 789-2000 (WORK)/ (206) 822-1329 (HOME) 

ROBERT EMERSON/ HONEYWELL INFORMATION SYSTEMS/ 9555 SE 36TH ST REET/ MERCER ISLAND WA 98040 

R. G. SHERRY/ 5828 FIRST AVE. N.W./ SEATTLE WA 98107/ (206) 78 3-0853 

PHIL HUGHES/ P.O. BOX 2847/ OLYMPIA MA 98507/ (206) 753-2315 

BUZZ HILL/ EYEDENTIFY INC./ P.O. BOX 2006/ LONGVIEW WA 98632/ (206) 423-3281 

FRED J. KELLER/ BUSINESS COMPUTER SYSTEMS/ DATACOMP/ P.O. BOX 1087/ SPOKANE WA 99210/ (509) 456-6908 

KEN ROBINSON/ DEPT. OF COMPUTER SCIENCE/ UNIVERSITY OF NEW SOUTH WALES/ P.O. BOX 1/ KENSINGTON H.S.W. 2033/ AUSTRALIA/ 663 0351 

DAVID POVJERS/ 259A TRAFALGAR STREET/ PETERSHAM N.S.W. 2049/ AUSTRALIA 

SIMON/ DEPT OF MATHEMATICS/ UNIV. OF NEWCASTLE/ NEWCASTLE N.S. W. 2308/ AUSTRALIA/ 68 5787 

ATTN: PURCHASING OFFICE/ RESEARCH SCHOOL OF PHYSICAL SCIENCES/ AUSTRALIAN NATIONAL UNIVERSITY/ P.O. BOX 4/ CAfJBERRA A.C.T. 2600/ AUSTRALIA/ 492143 

ATTN: SCHOOL OF INFORMATION SCIENCES/ CANBERRA COLLEGE OF ADVANCED EDUCATION/ P.O. BOX NO. 1/ BELCONNEN A.C.T. 2615/ AUSTRALIA 

JOHN EDWARDS/ LA TROBE UNIVERSITY/ BUNDOORA VICTORIA 3083/ AUS TRALIA/ 478 3122 

GEOFFREY A. CLEAVE/ 18 NEIL COURT/ E. BENTLEIGH VICTORIA 3165/ AUSTRALIA 

P. S. EDWARDS/ 2/100 BARRABOOL ROAD/ HIGHTON VICTORIA 3216/ AUSTRALIA 

J. S. ROHL/ DEPT. OF COMPUTER SCIENCE/ U OF WESTERN AUSTRALIA/ NEDLANDS W.A. 6009/ AUSTRAI.IA 

KARL PRAGERSTORFER/ EDERACKERSTRASSE 11/7/ LEONDING A-4060/ AUSTRIA/ (0043) 732-825392 

WIM STEVENS/ DRABSTRAiVT 49/ MORTSEL B-2510/ BELGIUM 

ROBERTO DIAS/ P.O. BOX 30028/ SAO PAULO/ BRAZIL 

PETER GROGONO/ 73 ROXTON CRESCENT/ MONTREAL WEST QUEBEC/ CANADA/ (514) 879-4251 (DAY) 

STUART LYNNE/ 315A EVERGREEN DR./ PORT MOODY B.C./ CANADA/ (60 4) 939-2757 

MAREK WIECHULA/ ST. FRANCIS XAVIER UNIV./ BOX 67/ ANTIGOHISH N • SCOTIA B2G ICO/ CANADA/ (902) 867-2275 

M. MICHEL COURCHESNE/ 11471 VALADE/ MONTREAL QUEBEC HIG 3S5/ CANADA/ (514) 324-5694/ (514) 281-8362 

GUY LAPALME/ DEPT. D' INFORMATIQUE/ UNIVERSITE DE MONTREAL/ C.P • 6128 - SUCC. A/ MONTRFAL QUEBEC H3C 3J7/ CANADA 

DANIEL THALMANN/ DEPT D' INFORMATIQUE ET RECHERCHE/ UNIV. DE MONTREAL/ CASE POSTALE 6128 - SUCC A/ MONTREAL QUEBEC H3C 3J7/ CANADA/ (514) 343-7477 

S. MATTHEWS/ AES DATA LTD./ 570 RUE MCCAFFREY/ MONTRFAL QUEBEC H4T INl/ CANADA/ (514) 341-5430 

M. JEAN-MARIE DIRAND/ SERVICE DE L' INFORMATIQUE/ UNIVERSITE DE SHERBROOKE/ 2500 BOUL. UNIVERSITE/ SHERBROOKE QUEBEC JIK 2R1/ CANADA/ (819) 565-5575 

JACQUES HAGUEL/ DEPT MATHS/ UNIVERSITE DE SHERBROOKE/ SHERBROO KE QUEBEC JIK 2R1/ CANADA/ (819) 565-3608 

H. TAYLOR/ COMPUTING CENTRE/ APPLICATIONS DEPT./ U OF OTTAWA/ OTTAWA ONTARIO KIN 6N5/ CANADA/ (613) 231-5094 

JACK HUGHES/ COMPUTING CENTRE/ DUPUIS HALL/ QUEEN'S UNIVERSITY / KINGSTON ONTARIO K7L 3N6/ CANADA/ (613) 547-2800/ (613) 547-2951 

D. R. WESTLUND/ 1478 FIRWOOO CRESCENT/ PETERBOROUGH ONTARIO K9 K IJI/ CANADA 

JAMES D. CALLADINE/ RR H CONCESSION 7/ OXBRIDGE ONTARIO LOC 1 KO/ CANADA 

CARLO LOCICERO/ 3501 GLEN ERIN DRIVE #401/ MISSISSAUGA ONTARIO L5L 2E9/ CANADA/ (416) 826-8640 

PETER ilAYNES/ CONTROL DATA CANADA LTD./ 1855 MINNESOTA COURT-S TREETSVILL\E/ MISSISSAUGA ONTARIO L5N 1K7/ CANADA/ (416) 826-8640 X238 

DAVID JONES/ CONTROL DATA CANADA LTD./ 1855 MINNESOTA COURT-ST RKKTSVILLE/ MISSISSAUGA 0>rTARIO L5N 1K7/ CANADA/ (416) 826-8640 X262 

CflRIS 8RYCE/ APPLIED MATH. COMPUTER LAii/ MCMASTER UNIVERSITY/ HAUILTOH ON'TARK) L8S 4Ki/ CAiJADA/ (416) 525-9140 X46S9 

ATTENTION: SANDRA WRIGHT/ DEFENCE & CIVIL INST. OF ENVIRt^WTL M ED/ P.O. B051 2000/ DOWNSVIEW ONTARIO M3M 3B9/ CANADA/ (416) 633-4240 X300 

TOM A. TROTTIER/ 411 DUPLEX AVE. - APT. 119/ TORONTO ONTARIO M AR 1V2/ CANADA/ (416) 488-8802 

RUSSELL JONES/ 427 ELM ROAD/ TORONTO ONTARIO M5M 3VJ6/ CAIUDA/ (416) 592-6758 (BUS)/ (416) 486-7756 (RES) 

ATTENTION: G. TER HOFSTEDE/ DATA CENTRE/ THE GLOBE AND MAIL/ 4 44 FROOT ST. WEST/ TORONTO ONTARIO M5V 2S9/ CATMDA 

ATTN: HELEN SMITH/ COMPUTER CENTER/ 1088B M AND C/ U OF WATERLOO/ WATERLOO ONTARIO N2L 3G1/ CANADA/ (519) 885-1211 X3430 

BILL WINSPUR/ COMPUTER SERVICES - HEALTH SCIENCES/ UNIVERSITY OF I>1ANIT0BA/ 753 MCDEIWOT AVE./ WINNIPEG MANITOBA R3E 0W3/ CANADA/ (204) 736-3630 

D. W. MACLEAN/ DEPT. OF MATHEMATICS/ UNIV. OF SASKATCHEWAN/ SASKATOON SASK. S7N OWO/ CANADA 

BETTY CLIFFORD/ COMPUTER SERVICES/ 058 MATH. SCIENCE/ UNIV. OF CALGARY/ 2920-24 AVE. N.W./ CALGARY AI.BERTA T2N 1N4/ CANADA 

ROBERT M. GREEN/ ROBELLE CONSULTING LTD./ 5421 lOTH AVE. - #13 0/ DELTA B.C. V4M 3T9/ CANADA/ (604) 943-8021 

GORDON STUART/ TECHNICAL AND VOCATIONAL INST./ CAMOSUN COLLEGE/ 1950 LANSDOWNE RD./ VICTORIA B.C. V8P 5J2/ CANADA/ (604) 592-1231 X248 

KEN SYLVESTRE/ 12 TAGISH ROAD/ WHITEHORSE YUKON YIA 3P5/ CANADA/ (403) 667-7372 

ATTN: CECICO/ UNIVERSIDAD CATOLICA DE CHILE/ CASILLA 114-D/ SANTIAGO/ CHILE/ 513548 

JWO-OT MOU/ COMPUTER SCIENCE DEPT./ CHIAO-TUNG UNIVERSITY/ HSI NCHU TAIWAN 300/ CHINA 

JOSEF JINOCH/ VVC CKD PRAHA/ PRAHA 9 NA HARFE 7/ CZECHOSLOVAK! A/ 820841/664 

ROLF MOLICH/ DANSK DATA ELEKTRONIK/ GENERATORVEJ 6A/ HERLEV DK-2730/ DENMARK/ 45 *? 84 50 11 

UFFE MOLLER/ DATANOMUDDANNELSEN/ LANGAGERVEJ 16/ AALBORG OST D K-9220/ DENMARK/ (08) 15 81 00 

ROBERTO ARGUETA/ CENTRO DE COMPUTO/ UNIVERSIDAD DE EL SALVADOR / SAN SALVADOR/ EL SALVADOR/ 260017 X50 

HANNU ERKIO/ DEPT. OF COMPUTER SCIENCE/ UNIVERSITY OF HELSINKI / TOOLOt^ATU 11/ HELSINKI 10 SF-00100/ FINLAND/ 90-440703 

HEIKKI KASKELMA/ OY SOFTPLAN AB/ EROTTAJANKATU 9 A/ HELSINKI S F-00130/ FINLAND/ (9) 0-644306 

ATTN:TECHNICAL RESEARCH CENTRE OF FINL/ COMPUTING SERVICE/ VUO RIMIEHENT 5/ ESPOO SF-02150/ FINLAND/ 90-4561 

ANTTI ARVELA/ RUNKOKATU 6 A 8/ TAMPERE 34 SF-33340/ FINLAND 

HANNU JAAKKOLA/ ITSENAISYYDENKATU 16 I 75/ TAMPERE 50 SF-33500 / FINLAND/ 931 612618 

MICHEL GALINIER/ LA GIRAGLIA/ ESPANES F-31450/ FRANCE 

ATTN: CENTRE DE RECHERCHE/ INFORMATIQUE ET GESTION/ UNIV. DES SCIENCES ET TECH. DU LANCUED/ AVENUE D'OCCITRAINE/ MONTPELLIER CEDEX F-34075/ FR,\NCE 
(67) 63-38-86 X339 

ATTN: DEPT DE MATHEMATIQUE AND INFORIIA/ BIBLIOTHEQUE 2 CYCLE/ C/O LE BAIL/ UNIVERSITE DE RENNES/ BP-25A/ RENNES CEDEX F-35031/ FRAflCE 

ATTN: UNIVERSITAT DE GRENOBLE/ SERVICE DE MATEMATIQUES APPLIQU EES/ CENTRE DE TRI/ BP N-53/ GRENOBLE CEDEX F-33041/ FRANCE 

BERNARD PERRETTE/ FABRICATION DES BILLETS/ BANQUE DE FRANCE/ B •?• 89/ P'UTEAUX F-92803/ FRANCE 

ATTN: FREIE UNIVERSITAT BERLIN/ FBIO-WEI/ FR ANGEWANDTE STATIS TIK/ CORRENSPLATZ 2/ BERLIN 33 D-1000/ GERJIANY 

ATTN: INSTITUT FUER INFORI-IATIK/ UNIVERSITAT HAMBURG/ SCHLUETER STRASSE 70/ HAMBURG 13 D-2000/ GERMANY 

THOMAS BERNER/ HElRt-lANN-KAUFFMANN STRASSE 35/ HAMBURG 60 D-2000 / GERMANY/ 040-2506602 

ATTN: INSTITUT FUR INFORMATIK/ UNIVERSITAT KIEL/ OLSHAUSENSTR. 40-60/ KIEL D-2300/ GERMANY 

KWAI-SAND LAM/ HEINRICHSTR. 7/ RHEINE D-4440/ GERMANY/ (0251) 706-3236 

DIETRICH KREKEL/ RECHEN ZENTRUM/ UNIVERSITAT ZU KOLN/ ROBERT KOCH STR 10/ KOLN 41 D-5000/ GERMANY/ 0221/478/5587 

PETER ALTMANN/ GRFr,ORSTR.26/ AACHEN D-5100/ GERMANY 

CH. SCHLIER/ FAKULTAT FUR PHYSIK DER UNIVERSITAT/ HERMANN-HERDER STR. 3/ FRIEBURG I. BR. D-7800/ GERMANY/ 0761/203 3714 

WERNER REMMELE/ ZT ZFE FL SAR 121/ SIEMENS AG/ OTTO-HAHN-RING 6/ MUNCHEN 83 D-8000/ GERMANY/ 089/6782-4622 

WILLIAM M. BRACK/ UNIV. AND POLY. COMPUTER CTR. LTD./ CORE C G /FL/ HONG KONG POLYTECHNIC/ YUK CHOI ROAD / HUNG HOM/ K0\rL00li/ HONG KONG 
S. M. VAIDYA/ REGIONAL COMPUTER CENTRE/ POONA UNIVERSITY/ POON A 411007/ INDIA 

INDRO S. SUWANDI/ COMPUTER SCIENCE CENTER/ UNIVERSITY OF INDON ESIA/ P.O. BOX 3442/ JAKARTA/ INDONESIA/ (021) 45726 

ALAN JONES/ 2 GROVE ROAD / HAI.AHIDE/ DUBLIN/ IRELAND 

JUDITH KOVETZ/ COMPUTATION CENTRE/ TEL-AVIV UNIVERSITY/ RAMAT- AVIV/ ISRAEL/ 03 420643 

TERUO HIKITA/ DEPT. OF MATHEMATICS/ TOKYO METROPOLITAN UNIV./ FUKAZAWA SETAGAYA-KU/ TOKYO 158/ Ji^AN/ 03-717-0111 

HIROAKI NISHIOKA/ SHOJI-HIGASHI 1-3-7/ IKUNO-KU OSAKA 544/ JAPAN/ 06-751-4891 

CHRIS M. BISHOP/ COMPUTING CENTRE/ UNIVERSITY OF OTAGO/ P.O. BOX 56/ DUNEDIN/ NEW ZEAI.AND/ DUNEDIN 40109 EXT 890 

ATTN: DOCUMENTATION OFFICER/ COMPUTER CENTRE/ MASSEY UNIVERSIT Y/ PALMERSTON NORTH/ NEW ZEAIAND 

OLAV NAESS/ WELHAVENSGT.65/ BERGEN/ NORWAY 

ADNNAN KHAN/ 222/7 BLOCK-E/ OPP. WALTON TRAINING CENTRE/ WALTON ROAD/ LAHORE CANTT./ PAKISTAN/ 83644/ 412193 

MICHAL IGLEWSKI/ INSTITUTE OF COMPUTER SCIENCE/ POLISH ACADEMY OF SCIENCE/ PKIN P.O. BOX 22/ V^ARSZAWA 00590/ POLAND/ 200211 X2225 

ADELINO CARLOS DE SOUSA/ RUA JOAO PINTO RIBEIRO 7-30 ESQ./ AMA DORA/ PORTUGAL/ 937 315 

JACK PAGE/ PAGE-ASIA ASSOCIATES/ 279-M SELEGIE COMPLEX/ SINGAP ORE-7/ SINGAPORE/ 326102 

JUDY M. BISHOP/ COMPUTER SCI. DIV. /APPLIED MATHS DEPT./ UNIV. OF THE WITWATERSRAND/ 1 JAN SMUTS AVENUE/ JOHANNESBURG 2001/ SOUTH AFRICA 

(11) - 394011 X8656 
PATRIK WAHREN/ HUGIN HASSREGISTER AB/ BOX 4180/ STOCKHOLM S-10 2 62/ SWEDEN/ 08/24 51 00 
MATS APELKRANS/ BOX 3032/ VAXJO S-350 03/ SWEDEN/ 0470/46363 

ANA-MARIA SCILMIT/ CMXULATRICES DIGITALES/ ECOLE POLYTECHNIQUE FEDERALE/ 16 CH. DE BELLERIVE/ LAUSANNE CH-1007/ SWITZERLAND/ 021 47 26 59 
RAYMOND MOREL/ 98 CH. DE LA MONTAGNE/ GENEVA CH-1224/ SWITZERLAND 

HANS J. METZDORF/ HAUPTPOSTLAGERND/ LUGANO CH-6900/ SWITZERLAND/ 0039/332/780131 X1079 

PETER U. SCHULTHESS/ INSTITUT FUER INFORMATIK/ UNIVERSITAET ZU ERICH/ KURVENSTRASSE 17/ ZUERICH CH-8006/ SWITZERLAND 
THE NETHERLANDS J. F. WILKES/ SHAPE TECHNICAL CENTRE/ POST BOX 174/ DEN HAAG/ THE NETHERLANDS 
THE NETHERLANDS TOM VAN DER HOEVEN/ HAGEDOORNSWEG/ NIEBERT/ THE NETHERLANDS 

UNITED KINGDOM J. A14BLER/ 21 KILKEVAN TERRACE - WHILFIELD/ DUNDEE SCOTLAND/ U NITED KINGDOM 

UNITED KINGDOM R. D. FREEMAN/ EDP DEPT./ PLESSEY CO. LTD./ TITCHFIELD NEAR FA REHAM/ HAMPSHIRE ENGLA^^)/ UNITED KINGDOM 
UNITED KINGDOM D. S. COCHRANE/ 4 ENNIS CLOSE/ HARPENDEN HERTS/ UNITED KINGDOM 
UNITED KINGDOM D. J. HOV/ORTH/ 27 CHILTERN ROAD/ HITCHIN HERTS/ UNITED KINGDOM 



APPLICATIONS 

PLEASE SUBMIT ALL PROGRAMS, SOFTWARE 
TOOLS, ALGORITHMS, etc. for 
this section to Rich. 



Editor: Rich Cichelli 901 Whittier Drive 
Allentown, PA 18103 
USA 
(phone: 1-215-253-6155 work 
Thanks, Andy. 1-215-797-9690 home) 



We decided to create a new section for printing Pascal source programs for various 
applications including software tools and algorithms. Additionally here, we will print 
news of significant applications programs written in Pascal. 

Jim Miner suggested we should index each program so that they may be easily referenced 
for corrections and criticisms. 

Arthur Sale is very enthusiastic about the algorithms section. He suggested that: 
we allow for 1) the provision for certification of the program by unrelated persons, with 
clear identification of system used; and 
2) critiques of the program for a) standards conformance, or b) style, or 
c) algorithm, or d) output convenience and general design. 

We'll number programs starting with P-1, software tools starting with S-1, and 
algorithms starting with A-1. 

New Software Section 

I am looking forward to your new software section in News, partly because I 
may see something really good there, but even more for the educative role I 
think it will play among Pascal users. I think back to the large influence 
that the CACM Algorithms section had on Algol stylistics and their propagat- 
ion, and on the appreciation of subtle points of the FORTRAN standard. 

So besides the big program things (which I shall enjoy perusing for their 
non-portable features) , may I suggest that News could serve as a useful 
vehicle for procedures and algorithms of very common use? For example, what 
about a portable lexical analyser for reference PASCAL (as in the Report) 
which itself had no assumptions about wordsize or setsize beyond those likely 
to hold in all compilers? Or a tree-balancer? And so on. I'm therefore 
enclosing a little thing to stir up those other contributors you have: a 
procedure to produce a 'Pascal standard time and date log record' . You will 
see that a little machine-dependency is not harmful to communication, provided 
it is collected and clearly identified as such. 



}d^%r 



Arthur Sale. 
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In PUGN # 6, John Banning wrote to solicit programs for his empirical study of Pascal 
programs. On 78/01/14 he wrote that he had a change in thesis topic which delayed 
his performing the study. He enclosed a listing of a 12000-line Pascal program 
which analyzes Pascal programs for style and behavior. 



In PUGN # 11, Prof. David Barron announced the formation of a numerical library 
project. He has recently been in touch with Jan Kok and Reind P. van de Riet of 
Vrije Universiteit and Mathematisch Centrum in Amsterdam, The Netherlands, who have 
constructed a large library for Pascal on CDC-6000 series machines. 

When numerical analyst Gilbert W. Stewart heard about the project, he was interested, 
and gave the advice that algorithms beware of the matrix storage differences between 
Pascal and FORTRAN (row-wise versus column-wise). 
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ALGORITHMS 



- 1 Random Number Generator 

Department of Computer Studies 

Bailrigg, Lancaster 

Telephone Lancaster 65201 (std 0524) 



University of Lancaster 



Head of Department: J. A. Llewellyn B.Sc, M.Phil., F.B.C.S., F.I.M.A. 



Dear Andy, 



30th November 1977. 



In case anyone is interested, as I am, in using Pascal for 
simulation pxirposes, I present a Pascal random number generator based 
on the feedback shift register pseudorandom number generator algorithm 
given by Whittlesey C Ij , for a 16-bit word size machine. 

Note that : 

i) for any other word size, the constants 'pshift', 'qshift' and 
»big' must be changed; (see Lewis [2]) 

ii) bound checking must be suppressed to allow the dual interpretation 
of variables as both integer and boolean (if anyone is offended by 
this objectionable programming trick, or if it fails to work under 
a particular implementation, I have a more portable version - but 
the price of portability is execution speed); 

similarly, overflow checking needs to be suppressed, but I have a 
remedy for this, too; 

iii) oiar implementation has whole word logical operations for and and 
or, but not for not - hence the use of 'acomp' and 'bcomp*; 
(note - a subsequent release restricts and and or to boolean operations 
only) 

iv) the function must initially be passed a positive non-zero integer 
"seed" (parameter 'x'), and will thereafter update this seed and 
yield a real number in the range (0,1J. 

The feedback shift register method has been shown by Lewis [2] to 
give good results, and I have thoroughly tested this version with the 
usual statistical tests. (Pascal procedures for these tests are 
available from me). 

Incidentally, I woxild be very pleased to hear from anyone else 
interested in Pascal and simulation. 



Mv 



Brian A. E. Meekings. 



References. 



Whittlesey, J.R.B. A ccxnparison of the correlational behaviour 
of random number generators for the IBM 360. Comm ACM 11,9 
(Sept 1968). 

Lewis, T.G. Distribution Sampldng for Computer Simulation. 
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function random ( var x: integer ); real ; 

const pshift = 2048; 
qshift = 16; 
big = 32767; 

type dual = record 

case dummy: boolean of 

true : (i: integer ) ; 

false : (b: boolean ) 
end ; 

var a , b , acoirp , bcomp : dual ; 

begin 

(* exclusive or number and number shifted 4 places right •) 

a.i := x; b.i := a.i div qshift; 

acomp.i := big - a.i; bcomp. i := big - b.i; 

a.b := (a.b and bcc«np.b) or (acomp.b and b.b); 

( * exclusive or number and number shifted 11 places left * ) 

b.i := a.i * pshift; 

acomp.i := big - a.i; bcomp. i := big - b.i; 

a.b := (a.b and bcomp. b) or (acomp.b and b.b); 

i" convert to real result *) 
x := a.i; 

random := a.i / big 
end ( * random * ) ; 



(* Jim Miner tried out the algorithm on a PDP8 (23 + 1 bit integers). He made 
following points: a) the results seemed to be better if the left-shift 
is circular ; b) one has to be careful of multiply overflow; c) the 
exclusive-or's are more naturally expressed as set operations, and d) a seed 
of zero yields a constant zero result. His version is printed below. *) 



FUNCTION RflNDOfKVFlR SEED; INTEGER:- ; REFiL; 
CONST 

PSHIFT = 65526; (* 2 - 16 *) 
PMOD = 128; ( * 2 •"• 7 *) 

QSHIFT =■■ 64; < * 2 "• 6 * ) 

MRKINT = 83:88607.1 <+ 2 "■ 23 - i *) 
VFIR 

a.. B: 

RECORD CfiSE BOOLEFiN OF 
TRUE; (I: INTEGER); 
FALSE; <S; FflCKED SET OF 6. . 23:); 
END; 
BEGIN 

H.I ;= HBS(SEED>; B.I ;= Fi. I DIV QSHIFT; (BRIGHT SHIFi 
H. S ;= (Fi. S - B. S) + (B. S - Fl. S); <* KOR =+= ) 
B. I ;= Fl. I MOD PMOD + PSHIFT + Fi. I DIV PMOD; 

(+LEFT SHIFT CIRCULAR 16+) 
H. S ;= (fl. S - B. S> + <B. S - Fi. S>; 
SEED ;= fi. I; RANDOM ;= A. I / <i. O + MAXINT!? 
END ORANDOM*) 



3> 
00 

3> 



00 



00 



CD 



A - 2 Timeloq 



DOCUMENTATION : TIME LOG 



Language : Pascal 



: A.H.J. Sale 
Thursday, 1978 March 2, 



3.20pin 



Use 



To improve the quality of production PASCAL programs by making available a 
standard method of recording the date and time of a run. 

User documentation 

Timelog is a Pascal procedure which writes on a globally declared file output, 
producing a single line which is a log-record of the date and time. It has 
no parameters, and is therefore used simply by including the text in the pro- 
cedure declaration part of a program, and then activated by calling: 

time log 

The format of the printed line is chosen to avoid all the confusion created 
by numeric date and time information by conflicting American, English and 
European conventions; in addition a measure of redundancy is included by the 
weekday name. See date given above as an example. 

Installation 

The procedure will work without modification on Burroughs B6700/7700 instal- 
lations using the University of Tasmania compiler. On other systems the 
machine-dependent part (identified clearly in the listing) will have to be 
altered to acquire the necessary information. (The B6700 pre-defined procedure 
timestamp puts year/month/day/hour /minute/ second information into the array 
parameter elements, thereby avoiding any timing glitches of separate calls.) 
The lower-case letters and some other characters may have to be converted to 
suit some systems' lexical requirements. The procedure is easily modified to 
handle other Indo-European languages (e.g. French) by altering the text strings. 

System documentation 

The procedure is straightforward. Only a few things are worth noting. 

(i) Zeller's congruence is used to compute the weekday from the epoch. 

(ii) The date and time are written according to ISO standard format in 
descending order of significance (apart from the weekday) . 

(iii) The minute value is printed without zero-suppression; other numeric 
codes are zero-suppressed, as is normal Pascal convention. 



00010000 
00010100 
00010200 
00010300 
00010400 
00010500 
00010600 
00010700 
00010800 
00010900 
00011000 
00011100 
00011200 
00011300 
00011400 
00011500 
00011600 
00011700 
00011800 
00011900 
00012000 
00012100 
00012200 
00012300 
00012400 
00012500 
00012600 
00012700 
00012800 
00012900 
00013000 
00013100 
00013200 
00013300 
00013400 
00013500 
00013600 
00013700 
00013800 
00013900 
00014000 
00014100 
00014200 
00014300 
00014400 
00014500 
00014600 
00014700 
00014800 
00014900 
00015000 
00015100 
00015200 
00015300 
00015400 
00015500 
00015600 
00015700 
00015800 
00015900 
00016000 
00016100 
00016200 
00016300 
00016400 
00016500 
00016600 
00016700 
00016800 
00016900 
00017000 
00017100 
00017200 
00017300 
00017400 
00017500 
00017600 
00017700 
00017800 
00017900 
00018000 
00018100 
00018200 
00018300 



procedure tim»to9; 



This procedure prints out a basic l09-rseord on th« output 
file. It avoids the well-known problems of American and 
English date conventions, and the 24-hour clock confusion. 



year 

month 

day 

hour 

minute 

epoch 



adjyear 
ad jmonth 
weekday 
adjustedhour 



01. .99; 

1..12; 

1..31; 

0..23; 

0..59; 



{ two digits, 19xx assum 

{ month number 

{ day in mo n t h 

{ 24-hour clock assumed 

{ minutes past the hour 



GO 

3> 



CO 



array[0. .5] of integer; 

{ required for B6700 



00.. 99; 
1..12; 
0..6; 
0..12; 



{ Jan & Feb are taken as 

{ last months of prev year 

{ OsSunday, isMonday, etc 

{ conventional-clock 



begin 

{ The statements betwee 



I ■■!« •latvmoiits w«iw»»ii horo snd the next comment should 

{ be replaced by the equivalent for your system. Note the 

{ ranges of the variables documented in the declarations. 

t imestamp(epoch) ; 

year :sepoch[0]-1900; 

month :sepoch[1]; 

day :sepoch[2]; 

hour :sepoch[3]; 

minute :=epoch[4]; 

( this closes the machine-dependent part ) 

{ compute the adjusted hour we use ) 

adjustedhour :shour mod 12; 

if (adjustedhour a 0) then ad justedhour :si2; 

{ adjust month and year information } 
if (month <s 2) then begin 

ad jmonth: =month*lO; ad jyear ::year-1 
end else begin 

adjmonth:smonth-2; adjyear :sysar 
end; 

{ zel ler ' s congruence } 
weekday :s 

(((26 « adjmonth - 2) div 10) * day * adjyear * 

(adjyear div 4) + 1) mod 7; 



CO 



wr I 
wr i 
wr I 
wri 
wr i 
wr i 



{ write th 
case weekd 
0: wr i 
1 
2 
3 
4 
5 
6 
end; 
wr i te(oytp 
case month 
1 : wr i 
2: wr I 
3: wri 
4: wri 
5: wri 
6: wri 
7 : wr i 
8: wr i 
9: wr i 



e timelog 

ay of 

te(output 

te(output 

te(output 

te(output 

te(output 

te(output 

te(output 



out } 

, ' Sunday' ) ; 

,'Monday'); 

, 'Tuesday' ) ; 

.'Wednesday'); 

, 'Thursday' ) ; 

,'Friday'); 

,'Saturday') 



wr I 
wr i 



10 

11 

12 

end; 

wr i te(outp 

(minut 

if (hour > 

wr itel 

end else b 

wr i tel 

end; 



t , 

of 

te(output 
te(output 
te(output 
te(output 
teloutput 
te(output 
te(output 
te(output 
te(output 
te(output 
te(output 
te(output 

t.' ',da 
div 10) 
s 12) the 
n(output , 
eg! n 
n(output , 



(year*1900):4,' '); 

, 'January' ) ; 
, 'February' ) ; 
, 'March'); 
, 'April'); 
.'May'); 
, 'June' ) ; 
,'July'); 
.'August' ) ; 
. 'September' ) ; 
. 'October' ) ; 
, 'November' ) ; 
, 'December' ) 

y:2,' . ' .adjustedhour :2, 
:1 , (minute mod 10) :1) ; 
n begin 
' PM.') 

' AM.') 



CD 



SOFTWARE TOOLS 



S - 1 Compare 



1 <* 

2 * 

3 * 

4 * 

5 * 

6 * 

7 * 

8 * 

9 * 

10 * 

11 * 

12 * 

13 * 

14 * 

15 * 

16 * 

17 * 

18 * 

19 * 

20 > 
21 
22 

23 {* 

24 * 

25 * 

26 * 

27 * 

28 * 

29 * 

30 * 

31 * 

32 * 

33 * 

34 * 

35 * 

36 * 

37 * 

38 * 

39 * 

40 * 

41 * 

42 * 

43 * 

44 * 

45 * 

46 * 

47 * 

48 * 

49 * 

50 * 

51 * 

52 * 

53 * 

54 * 

55 * 

56 * 

57 } 
58 



COMPARE - Compare two text files and report their differences 

Copyright (C) 1977, 1978 

James F. Miner 

Social Science Research Facilities Center 

University of Minnesota 

General permission to make fair use in non-profit activities 
of all or part of this material is granted provided that 
this notice is given. To obtain permission for other uses 
and/or machine readable copies write to: 

The Director 

Social Science Research Facilities Center 

25 Blegen Hall 

269 19th Ave. So. 

University of Minnesota 

Minneapolis, Minnesota 55455 

USA 



Compare is used to display on "Output" the differences 
between two similar texts ("Filea" and "Fileb"). Notable 
characteristics are: 

- Compare is line oriented. The smallest unit of comparison 
is the text line (ignoring trailing blanks). The present 
implementation has a fixed maximum line length. 

- By manipulating a program parameter, the user can affect 
Compare's sensitivity to the "locality" of differences. 
More specifically this parameter, "Minlinesf ormatch" , 
specifies the number of consecutive lines on each file 
which must match in order that they be considered as 
terminating the prior mismatch. A large value of 
"Minlinesf ormatch" tends to produce fewer but larger 
mismatches than does a small value. The value six appears 
to give good results on Pascal source files but may be 
inappropriate for other applications. 

If compare is to be used as a general utility program, 
"Minlinesf o rmatch" should be treated as a program 
parameter of some sort. It is declared as a constant here 
for portability's sake. 

- Compare employs a simple backtracking search algorithm to 
isolate mismatches from their surrounding matches. This 
requires (heap) storage roughly proportional the the size 
of the largest mismatch, and time roughly proportional to 
the square of the size of the mismatch for each mismatch. 
For this reason it may not be feasible to use Compare on 
files with very long mismatches. 

- To the best of the author's knowledge. Compare utilizes 
only features of Standard Pascal. 
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60 program compare ( filea , fileb, output): 

61 

const 

version = ' 1 . 2p (78/03/01)'; 



62 
63 
64 
65 
66 
67 
68 
69 
70 
71 
72 
73 
74 
75 
76 
77 
78 
79 
80 
81 
82 
83 
84 
85 
86 
87 
88 
89 
90 
91 
92 
93 
94 
95 
96 
97 
98 
99 
100 
101 
102 
103 
104 
105 
106 
107 
108 
109 
110 
111 
112 
113 
114 
115 
116 
117 
118 
119 
120 



linelength = 120; 
minlinesf o rmatch = 6; 



{ MAXIMUM SIGNIFICANT INPUT LINE LENGTH } 
{ NUMBER OF CONSECUTIVE EQUIVALENT } 
< LINES TO END A MIS-MATCH } 



{ SINGLE LINE BUFFER } 



t ype 

linepointer = '"line; 
line = 

packed record 

nextline : linepointer; 
length : .. linelength ; 

image : packed array [ 1 .. linelength] £f char 
end ; 



GO 



GO 



Stream = 
record 

cursor, head, tail : linepointer; 

cursorlineno, headlineno, taillineno 

endfile : boolean 
end ; 

var 

filea, fileb : text; 
a, b : stream; 
match : boolean; 
endfile : boolean; 



{ BOOKKEEPING FOR EACH INPUT FILE } 



integer; 



templine : 

record 
length 
image : 

end ; 



< SET IF END OF STREAM A OR B } 
{ USED BY READLINE } 



: integer; 
array [0 . .linelength] ^ char 



CD 

oo 



freelines : linepointer; 
same : boolean; 

procedure c omparef iles ; 



{ FREE LIST OF LINE BUFFERS } 

< FALSE IF NO MIS-MATCHES OCCUR } 



function ends tream (var x : stream) : boolean; 
begin { ENDSTREAM } 

endstream := (x. cursor = nil ) and x. endfile 
end ; { ENDSTREAM } 

procedure mark( var x : stream) ; 

{ CAUSES BEGINNING OF STREAM TO BE POSITIONED BEFORE } 
{ CURRENT STREAM CURSOR. BUFFERS GET RECLAIMED, LINE } 
< COUNTERS RESET, ETC. > 



var 
P 



linepointer ; 



begin { MARK > 
with X d_o 

if head <> nil then 
begin 



3> 
CD 

m 
ho 

CD 



121 
122 
123 
124 
125 
126 
127 
128 
129 
130 
131 
132 
133 
134 
135 
136 
137 
138 
139 
140 
141 
142 
143 
144 
145 
146 
147 
148 
149 
150 
151 
152 
153 
154 
155 
156 
157 
158 
159 
160 
161 
162 
163 
164 
165 
166 
167 
168 
169 
170 
171 
172 
173 
174 
175 
176 
177 
178 
179 
180 
181 
182 



while head <> cursor do { RECLAIM BUFFERS } 
begin 

with head'^ do 

begin p := nextline; 

nextline := freelines; freelines := head 
end ; 
head := p 
end ; 
headlineno := cur so rlineno ; 
if cursor = nil then 

begin tail := nil ; taillineno := cursorlineno end 
end 
end ; { MARK > 

procedure inovecursor( var x : stream; var filex : text); 

{ FILEX IS THE INPUT FILE ASSOCIATED WITH STREAM X. THE > 

{ CURSOR FOR X IS MOVED FORWARD ONE LINE, READING FROM X > 

{ IF NECESSARY, AND INCREMENTING THE LINE COUNT. ENDFILE > 

{ IS SET IF EOF IS ENCOUNTERED ON EITHER STREAM. } 

procedure readline; 
var 

newline : linepointer; 
c, c2 : . .linelength ; 
begin { READLINE } 

if not x.endfile then 
begin 

c := 0; 

while not eoln(f ilex) and (c < linelength) do 

begin c := c + 1; temp line . image [c ] := filex'^; get(filex) 
readln (filex) ; 

while templine. image [c ] = ' ' d_o c := c - 1; 
i f c < templine. leng th then 

for c2 := c+1 t_o templine. length djo templine . image [c2 ] := ' 
templine. leng th := c; 
newline := freelines; 
if newline = nil then new(newline) 
else freelines := freelines"^ .nextline ; 
pack( templine. image , 1, newline'" . image) ; 
newline^ . length ;= c; 
newline*^ . nextline := nil ; 
if x.tail = nil then 

begin x.head := newline; 

X. taillineno := 1; x. headlineno := 1 
end 
else 

begin x . tail'' .nextline := newline; 
X. taillineno := x. taillineno + 1 
end ; 
x.tail := newline; 
x.endfile := eof(filex); 
end 
end ; < READLINE } 

begin < MOVECURSOR } 

if X. cursor <> nil then 
begin 

if X. cursor = x.tail then readline; 
X. cursor := x . cur sor'^ .nextline ; 
if X. cursor = nil then endfile := true; 
X . cur sor lineno := x . cur sorlineno + 1 



183 
184 
185 
186 
187 
188 
189 
190 
191 
192 
193 
194 
195 
196 
197 
198 
199 
200 
201 
202 
203 
204 
205 
206 
207 
208 
209 
210 
211 
212 
213 
214 
215 
216 
217 
218 
219 
220 
221 
222 
223 
224 
225 
226 
227 
228 
229 
230 
231 
232 
233 
234 
235 
236 
237 
238 
239 
240 
241 
242 
243 
244 
245 



CO 

=9= 



3> 

end t>o 

e^se ^ 

if not x.endfile then { BEGINNING OF STREAM > -^ 

begin ^ 

readline; x. cursor := x.head; 

X . cur so rlineno := x. headlineno ^^ 

end m 

else { END OF STREAM } ^ 

end f ile : = true ; 

end ; { MOVECURSOR > 

procedure b acktrack( var x : stream; var xlines : integer); j,^ 

< CAUSES THE CURRENT POSITION OF STREAM X TO BECOME THAT > 

< OF THE LAST MARK OPERATION. I.E., THE CURRENT LINE } 

< WHEN THE STREAM WAS MARKED LAST BECOMES THE NEW CURSOR. } 

{ XLINES IS SET TO THE NUMBER OF LINES FROM THE NEW CURSOR } 

< TO THE OLD CURSOR, INCLUSIVE. > 

begin { BACKTRACK } 

xlines := x . cur sorlineno + 1 - x. headlineno ; 

X. cursor := x.head; x . cur sor lineno := x. headlineno ; 

endfile := endstream(a) o^ endstream(b) 
end; < BACKTRACK > 

procedure comparelines ( var match : boolean); 

c_ 
{ COMPARE THE CURRENT LINES OF STREAMS A AND B, RETURNING > ^_ 

< MATCH TO SIGNAL THEIR (NON-) EQUIVALENCE. EOF ON BOTH STREAMS } ^ 
{ IS CONSIDERED A MATCH, BUT EOF ON ONLY ONE STREAM IS A MISMATCH } ^ 

begin { COMPARELINES > 

if (a. cursor = nil ) or (b. cursor = nil ) then H-* 

match := endstream(a) and endstream(b) ^^ 

else ^ 

begin OO 

match := ( a . cur sor^ . leng th = b . cur so r'" . leng th) ; 

if match then 

match := (a . curso r'" . image = b . cur sor^ . image ) 
end 
end ; { COMPARELINES > 

procedure f indmlsma tch ; 
begin < FINDMISMATCH } 

{ NOT ENDFILE AND MATCH > 
repeat { COMPARENEXTLINES > 

movecursor (a , filea); movecur so r (b , f ileb ) ; 
mark(a); mark(b); 
comparelines (match) 
until endfile ojc^ not match; 
end ; { FINDMISMATCH > 

procedure findmatch; 
var 

advanceb : boolean; { TOGGLE ONE-LINE LOOKAHEAD BETWEEN STREAMS > ^ 

procedure search( var x : stream; { STREAM TO SEARCH } ^ 

var filex : text; p-p, 
var y : stream; { STREAM TO LOOKAHEAD > 

var f iley : text) ; f^ 

I— » 

{ LOOK AHEAD ONE LINE ON STREAM Y, AND SEARCH FOR THAT LINE > 
{ BACKTRACKING ON STREAM X. } 



246 
247 
248 
249 
250 
251 
252 
253 
254 
255 
256 
257 
258 
259 
260 
261 
262 
263 
264 
265 
266 
267 
268 
269 
270 
271 
272 
273 
274 
275 
276 
277 
278 
279 
280 
281 
282 
283 
284 
285 
286 
287 
288 
289 
290 
291 
292 
293 
294 
295 
296 
297 
298 
299 
300 
301 
302 
303 
304 
305 
306 
307 
308 



count : integer; { NUMBER OF LINES BACKTRACKED ON X > 

procedure checkf ullma tch; 

{ FROM THE CURRENT POSITIONS IN X AND Y, WHICH MATCH, } 
{ MAKE SURE THAT THE NEXT MINLINESFORMATCH-1 LINES ALSO } 
< MATCH, OR ELSE SET MATCH := FALSE. } 
var 

n : integer; 

savexcur, saveycur : linepointer; 

savexline, saveyline : integer; 
begin < CHECKFULLMATCH } 

savexcur := x. cursor; saveycur := y. cursor; 

savexline := x. cur sorlineno ; saveyline := y .cur sorlineno ; 

compar elines (ma tch) ; 

n := minlinesf ormatch - 1; 

while match and (n <> 0) do 

begin movecursor (x, filex); movecur sor (y , f iley) ; 
comparelines (match) ; n := n - 1 

end ; 
X. cursor := savexcur; x. cursorlineno := savexline; 
y. cursor := saveycur; y .cursorlineno := saveyline; 
end ; < CHECKFULLMATCH } 

begin < SEARCH } 

movecur sor (y , filey); backtrack(x, count); 
checkf ullmatch ; count := count - 1; 
while (count <> 0) and not match do 
begin 

movecursor (x , filex); count := count - 1; 
checkf ullmatch 
end 
end; < SEARCH } 

procedure printmismatch ; 
var 

emptya, emptyb : boolean; 

procedure writetext(p, q : linepointer); 
begin { WRITETEXT } 
wr iteln; 

while (p <> nil) and (p <> q) do 
begin writeC * ' ) ; 

if p'". length = then writeln 
else writeln(p'". image : p". length); 
p := p'*".nextline 
end ; 
ii P = nil then writelnC *** eof ***'); 
writeln 
end; { WRITETEXT } 

procedure wr itelineno ( var x : stream); 

var 

f, 1 : integer; 
begin < WRITELINENO } 

f := x.headlineno ; 1 := x . cur sorlineno - 1; 

wr ite( ' line' ) ; 

if f = 1 then writeC ', f:l) 

else writers ', f:l, ' to ', 1:1); 

if X. cursor = nil then writeC (before eof)'); 
end; { WRITELINENO } 



309 
310 
311 
312 
313 
314 
315 
316 
317 
318 
319 
320 
321 
322 
323 
324 
325 
326 
327 
328 
329 
330 
331 
332 
333 
334 
335 
336 
337 
33§ 
339 
340 
341 
342 
343 
344 
345 
346 
347 
348 
349 
350 
351 
352 
353 
354 
355 
356 
357 
358 
359 
360 
361 
362 
363 
364 
365 
366 
367 
368 
369 
370 



procedure printextra text ( var x : stream; xname : char; 

var y : stream; yname : char); 
begin < PRINTEXTRATEXT } 

write(' extra text on file', xname, ', '); 
wr itelineno(x) ; writeln; 
if y.head = nil then 

writeln(' before eof on file', yname) 
else 

writeln(' between lines ', y .headlineno- 1 : 1 , ' and ', 
y .headlineno : 1 , ' of file', yname); 
wr itetex t (x.head , x. cursor) 
end ; { PRINTEXTRATEXT } 

begin { PRINTMISMATCH } 

writeln(' ***********************************'); 
emptya := (a. head = a. cursor); 
emptyb := (b.head = b. cursor); 
if emptya ^r^ emptyb then 

if emptya then printextratex t (b , 'b', a, 'a') 
else printextratext (a , 'a', b, 'b') 
else 
begin 

writeln(' mismatch:'); writeln; 

write(' filea, '); wr it elineno (a) ; wr iteln( ' : ' ) ; 
writetext (a .head , a. cursor); 

write(' fileb, '); writelineno (b) ; wr iteln( ' : ' ) ; 
writetext (b .head , b. cursor) 
end 
end ; < PRINTMISMATCH } 

begin { FINDMATCH > 
{ NOT MATCH } 
advanceb := true; 
repeat 

if not endfile then advanceb := not advanceb 
else advanceb := ends tream(a) ; 
if advanceb then search(a, filea, b, fileb) 
else search(b, fileb, a, filea) 
until match; 
printmismatch; 
end ; { FINDMATCH } 



GO 



m 

GO 

:«= 
I— » 



oo 



begin { COMPAREFILES } 
match := true; { I.E 
repeat 

if match then findmismatch else begin sam^ 
until endfile and match; 



BEGINNINGS-OF-FILES MATCH > 

false; findmatch end 



{ MARK(A); MARK(B); MARK END OF FILES, THEREBY DISPOSING BUFFERS } 
end ; { COMPAREFILES } 

procedure initialize; 

procedure ini t s tream( var x : stream; var filex : text); 
begin { INITSTREAM } 
with X do 
begin 

cursor := nil ; head := nil ; tail := nil ; 
cursorlineno := 0; headlineno := 0; taillineno := 
end ; 
reset (filex) ; x. endfile := eof(filex); 
end ; < INITSTREAM } 



CD 
m 



S - 2 Augment and Analyze 



371 
372 
373 
374 
375 
376 
377 
378 
379 
380 
381 
382 
383 
384 
385 
386 
387 
388 
389 
390 
391 
392 
393 
394 
395 



begin { INITIALIZE } 

initstream(a, f ilea) ; init stream(b , fileb); 

endfile := a.endfile ^r^ b.endfile; 

freelines := nil ; 

templine. length := linelength; 

templine.image[0] := 'x'; { SENTINEL } 
end; {INITIALIZE) 



begin 
ini 
pag 
wr i 
wr i 
wr i 
wr i 
if 
±± 

ii 

b 



{COMPARE} 
tialize ; 
e(output ) ; 

teln(' compare. version ', version) 

teln; 

teln(' match criterion = ', minlinesform 
teln; 

a.endfile then writeln(' filea is empty 
b.endfile then writeln(' fileb is empty 
not endfile then 
egin same := true; 

comparef iles ; 

if same then writeln(' no differences, 
nd 

{ COMPARE } 



lines . ' ) ; 



'); 
'); 



(* The following output from Compare was generated on a CDC Cyber 74. The data used was the 
source text of the Compare program itself, modified in 3 places by performing a change, a 
deletion, and an insertion. The original source is "File A". *) 



COMPARE. VERSION 1.2P (78/03/01) 
MATCH CRITERION = 6 LINES. 

*********************************** 

MISMATCH: 

FILEA, LINE 101: 

* PROCEDURE COMPAREFILES; 
FILEB, LINE 101: 

* PROCEDURE COMPAREFOOLS; 

*********************************** 

EXTRA TEXT ON FILEA, LINE 131 
BETWEEN LINES 130 AND 131 OF FILEB 

* BEGIN TAIL := NIL; TAILLINENO := CURSORLINENO END 

*********************************** 

EXTRA TEXT ON FILEB, LINE 162 
BETWEEN LINES 162 AND 163 OF FILEA 



PERFORMANCE MEASUREMENT OF PASCAL PROGRAMS 
USING AUGMENT AND ANALYZE 

- Andy Mickel 78/03/14. 

University Computer Center 
University of Minnesota 
Minneapolis, MN 55455 



What AUGMENT and ANALYZE Do 

Suppose you want to examine the execution efficiency of your Pascal 
program — perhaps to make improvements to those parts which take the most 
computer time. 

AUGMENT and ANALYZE are designed to obtain rough measures of such 
execution times, particularly for large Pascal programs. Unlike other kinds 
of performance measurement, AUGMENT and ANALYZE assume the PROCEDURE and 
FUNCTION to be the smallest unit of a program to be monitored. This is a 
satisfactory assumption because well-written Pascal programs produced by 
stepwise refinement naturally are composed of proper-sized procedures and 
functions. 

The general principle used by these programs is that the value of the 
non-standard Pascal function CLOCK (which returns the elapsed processing 
time in milliseconds) can be sampled at procedure or function entry and exit. 
When the the expression (exittirae - entrytime) , is evaluated the time spent 
within the particular procedure or function can be ascertained. 

AUGMENT is the program which inserts the necessary CLOCK-sampling 
code into your Pascal source program for every procedure and function entry 
and exit. It thus causes your program to capture timing information 
and to write it out to a file. 

Next you compile and execute your program, which actually produces the 
file of dynamic timing measurements. 

ANALYZE then reads the timing file produced, and writes a report, which 
gives the name of each procedure or function, the number of times it 
was called, and the execution time it consumed for all calls and per call. 

AUGMENT and ANALYZE therefore provide a nearly machine-independent 
method for gathering performance-measurement data about a Pascal program. 
Most Pascal implementations have the required CLOCK function which returns 
the elapsed processor time in milliseconds. 

It is sometimes necessary to exclude the monitoring of excessively 
called procedures and functions in large programs. A feature of AUGMENT 
allows you to specify any number of names to be excluded. 

How to Use AUGMENT and ANALYZE 



GO 

3> 



CO 



OO 



GARBAGE; 



Under CDC 6000/Cyber 70,170 operating systems, AUGMENT and ANALYZE are 
control statements. Thus the following 3 batch commands do the job: 

AUGMENT(the file name of your Pascal source program) 

PASCAL (INT ER/L- , G+) 

ANALYZE. 

The program headings for AUGMENT and ANALYZE are: 

AUGMENT (INPUT, EXCEPT, INTER, INTER2, OUTPUT) 

where: 

INPUT is the textfile containing the Pascal source program to be 
AUGMENTed. 



m 



EXCEPT is the textfile containing a list of names (one to a line 
with no leading blanks) of procedures and functions to be 
excluded from measurement. EXCEPT can be an empty file in which 
case no procedures or functions will be excluded. 

INTER is the textfile on which the AUGMENTed version of 
the Pascal source program is written. 

INTER2 is the binary file on which only the names of each 
procedure and function in the Pascal source program 
is written for use by ANALYZE. 

OUTPUT is the textfile on which error messages are written 

if problems occur during AUGMENTing. A report is written 
on OUTPUT verifying which procedures or functions were 
excluded, if any. 

The error messages are: 
*T00 MANY PROCEDURES AND FUNCTIONS TO AUGMENT. 

(A limit of 2000 is imposed.) 
*"BEGIN" EXPECTED. 
*"END" EXPECTED. 

(There's something wrong with the statement part 
of the Pascal source program which is being 
AUGMENTed; it began with some reserved symbol 
other than "begin" or there weren't enough 
"END"s to match "BEGIN"s.) 
*"PR0GRAI4" EXPECTED. 

(AUGMENT couldn't find "PROGRAM" as the first 
reserved symbol in the Pascal source program. 
Possibly the INPUT file was empty.) 
*UNDECUARED LABEL. 

AUGMENT couldn't find a label referred to by a 
GOTO statement. 



ANALYZE( OUTPUT, INTER2, TIMING) 

where : 

OUTPUT is the textfile on which the performance measurement 

report is written or alternatively the error message: 
*TIMING FILE EMPTY. 
INTER2 is the binary file on which the names of each procedure 

and function in the Pascal source program was written by 

AUGMENT. 
TIMI?IG is the binary file containing the dynamic timing 

measurements resulting from execution of the AUGMENTed 

Pascal program. 

Note: The identifier "TIMING" is added to the Pascal source 
program by AUGMENT and must not appear in any procedure or function 
which is to be monitored. When you use AUGMENT and ANALYZE, it is 
probably a good idea to consider the file names INTER, INTER2, and 
TIMING reserved. 

In summary, there are four steps to the performance measurement 
process: 

1) [Pascal source program] -> AUGMENT -> INTER and INTER2 

2) INTER -> PASCAL Compiler -> [Pascal binary program] 

3) [input data for 

Pascal program] -> Pascal binary program -> TIMING and [results 
********************* from Pascal program] 

4) TIMING and INTER2 -> ANALYZE -> [performance measurement report] 

******* 



Below are a test program, its AUGMENTed version, and the performance 
measurement report: 

The source of the test program: 

PROGRAM TEST(OUTPUT) ; 
LABEL 5; 
VAR N: INTEGER; 

PROCEDURE A; 

PROCEDURE B; 
BEGIN N := N + 1; 

IF ODD(N DIV 2) THEN A ELSE B 
END (*B*) ; 

BEGIN (*A*) 

N := N + 1; 

IF N > 200 THEN GOTO 5; 

B 
END (*A*) ; 
BEGIN N := 0; A; 5: END. 

The AUQlENTed version of the test program: 

PROGRAM TEST (OUTPUT, TIMING); 

LABEL 5 ; 

VAR 
TIMING:FILE OF PACKED RECORD I : 0. .2000;T : 0. .99999999;M:0. .2 END; 
N: INTEGER; 

PROCEDURE A; 

PROCEDURE B; 
BEGIN 
WITH TIMING'" DO BEGIN I:= 3;T:=CLOCK;M:=0 END;PUT(TIMING) ; 
N := N + 1; 

IF ODD(N DIV 2) THEN A ELSE B 

WITH TIMING^ DO BEGIN I:= 3;T:=CL0CK;M:=1 END; PUT (TIMING) 
END 
(*B*) ; 

BEGIN 
WITH TIMING" DO BEGIN I:= 1 ;T:=CLOCK;M:=0 END;PUT(TIMING) ; 
(*A*) 

N := N + 1; 

IF N > 200 THEN BEGIN 
WITH TIMING" DO BEGIN I:= 2;T:=CLOCK;M:=2 END ; PUT ( TIMING) ; 
GOTO 5 END 



GO 

3> 



GO 



OO 



WITH TIMING" DO BEGIN I:= 
END 

(*A*) ; 
BEGIN REl^RITE(TIMING); 
WITH TIMING" DO BEGIN I:= 

N := 0; A; 5: ; 
WITH TIMING" DO BEGIN I:= 
END 



2;T:=CL0CK;M:=1 END; PUT (TIMING) 

1 ;T:=CLOCK;M:=0 END; PUT (TIMING) ; 
1;T:=CL0CK;M:=1 END;PUT(TLMING) 



3> 



4=- 



The report from ANALYZE: 



PERFORMANCE MEASUREJIENT SUMMARY FOR PASCAL PROGRAl^: TEST 



MODULE 

NAME 

A 
B 
TEST 

TOTALS 



CALLS 
TIMES PERCENT 
CALLED OF TOTAL 



EXECUTION TIME 

(MILLISECONDS) 
AVERAGE MODULE PERCENT 
PER CALL TOTAL OF TOTAL 



52 

151 

1 

204 



25.490 

74.020 

0.490 

100.000 



0.15 


8 


27.586 


0.13 


20 


68.966 


1.00 


1 


3.448 




^ :=:»===. 




0.14 


29 


100.000 



From the summary provided by AUGMENT and ANALYZE, you can identify 
which procedures and fxmctions to improve for greater execution 
efficiency. In general, it pays to concentrate on procedures and 
functions which are frequently called and take a significant amount 
of the execution time of the total program. Procedures and functions 
which have a large average execution time per call, but which are only 
called a few times are not worth worrying about. 

If one or more procedures or functions seem to dominate the results 
it might be a good idea to monitor the program with these modules 
excluded from measurement. Use the except feature provided by AUGMENT. 



History 



AUGMENT and ANALYZE were conceived originally under the names PROFILE 
and PRINRES in 1975-1976 by S. Matwin and M. Missala, of the Polish Academy 
of Sciences Computer Centre, PKiN, Warwaw, Poland. The goal of the project 
was to build a simple tool to measure very large programs — such as the 
Pascal compiler itself. A paper describing their successful work entitled: 
"A Simple, Machine Independent Tool for Obtaining Rough Measures of Pascal 
Programs," appeared in SIGPLAN Notices (11:8) August, 1976, pages 42-45. 

Their successful implementation was on CDC machines using Pascal-6000. 

In 1976, Richard J. Cichelli of Lehigh University Mathematics Department 
and the American Newspaper Publishers Association Research Institute, obtained 
the programs and documented and distributed them to the Pascal community in the 
United States. 

In 1977, Herb Rubenstein and Andy Mickel of the University of Minnesota 
Computer Center, modified the programs for coding style and to increase 
portability, fixed bugs, and improved the performance of the programs 
themselves. We also removed several limitations (the built-in 
restrictions regarding the use of non-local GOTOs within procedures and 
functions as well as the monitoring of procedures named NEXTCH). 

The programs are now supported with the Pascal-6000 system which is 
distributed to CDC installations around the world. 

(* Note: In the programs listings following, 
empty comments denote lines with possible 
or outright machine dependencies. *) 



AUGMENT - AUGMENT PASCAL PROGRAMS WITH CODE TO GATHER 
EXECUTION TIME PERFORMANCE MEASUREMENTS. 

S. MATWIM AND 

M. MISSALA 1975. 

POLISH ACADEMY OF SCIENCES COMPUTER CENTRE. 

PKIN, WARSAW POLAND. 



REFERENCE: 



1 
2 
3 

5 

6 

7 

8 

9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 program augment( input , except, inter, inter2, output); 

48 

49 label 

50 

51 

52 cor 

53 

54 

55 

56 {} 

57 {} 

58 {} 
59 
60 
61 
62 
63 
64 



"A SIMPLE MACHINE INDEPENDENT 
TOOL FOR OBTAINING ROUGH MEASURES 
OF PASCAL PROGRAMS." 
SIGPLAN NOTICES . 1976 AUGUST, PP. 42-45. 



MODIFIED, GENERALIZED, AND RENAMED 
FROM "PROFILE" TO "AUGMENT" BY: 
A. B. MICKEL 77/08/04. 

H. U. RUBENSTEIN 77/06/01. 
UNIVERSITY OF MINNESOTA COMPUTER CENTER 
MINNEAPOLIS, MN 55455 USA. 

THE NAMES AND ORGANIZATIONS GIVEN HERE MUST NOT 3E 
DELETED IN ANY USE OF THIS PROGRAM. 

SEE THE PTOOLS WRITEUP (UNDER MEASURE) FOR 
EXTERNAL DOCUMENTATION. 



AUGMENT (INTERNAL DOCUMENTATION). 

AUGMENT INSERTS CODE TO CREATE A TIMING FILE IN THE PROGRAM 
HEADER, DECLARATION PART, AND STATEMENT PART OF THE PROGRAM 
TO BE MONITORED. CODE IS ALSO INSERTED IN THE STATEMENT 
PART OF EACH PROCEDURE AND FUNCTION TO WRITE CLOCK 
MEASUREMENTS (AT ENTRY, EXIT, OR GOTOENTRY) TO THE TIMING 
FILE WHEN THE PROGRAM IS EXECUTED. 

AUGMENT MUST PARSE A SUBSET OF PASCAL AND THEREFORE HAS A 
LEXICAL ANALYZER. THE TIMING FILE IS PROCESSED BY THE 
COMPANION PROGRAM CALLED ANALYZE. 



GO 



GO 



OO 



{$R-,T-,P-,U+ 



13 {EXIT FOR PROGRAM ERRORS}; 



beginsy 


= 


1 




casesy 


= 


2 




endsy 


= 


3 




externsy 


= 


4 




fortransy 


= 


5 




forwardsy 


= 


6 




f uncsy 


= 


7 




gotosy 


= 


8 




labelsy 


= 


9 




procsy 


= 


10; 


programsy 


= 


N; 


varsy 


= 


1. 


p . 



CD 

m 



65 
66 
67 
68 
69 
70 
71 
72 
73 
74 
75 
76 
77 
78 
79 
80 
81 
82 
83 
84 
85 
86 
87 
88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 

100 

101 

102 

103 

104 

105 

106 

107 

108 

109 

110 

111 

112 

113 
114 
115 
116 
117 
118 
119 
120 
121 
122 
123 
124 
125 
126 
127 
128 
129 
130 



maxrnodules = 2000; 

Umax = 120 { LINE LENGTH MAX 
llmin = 72 { LINE LENGTH MIN 
alfaleng = 10; 



type 



alfa 

codetype 

symbols 

naraenode 



modulecnt 

labelptr 

labelnode 



idlen, 

lastidlen: 

sy: 

chbuf : 

identifier: 

number: 

key: 

badnames, 

readinglabels; 

linelength, 

colcnt: 

ch: 

inter: 

except: 

inter2: 

badlist: 

count: 



procedure nextch; 



packed array [ 1 
(entry 



alfaleng] of char; 

exit, gotoentry, declare); 



beginsy ,. varsy; 
record 

name: alfa; 

link: " namenode 
end ; 

. . maxinodules; 
" labelnode; 
record 

TaEl: .. 9999; 

declaredin: modulecnt; 

next: labelptr 
end { LABELNODE }; 



{IDENTIFIER LENGTH} 
. . alfaleng; 
symbols; 

array [1 .. alfaleng] of char; 
alfa; 

.. 9999; 
array [symbols] of alfa; 

boolean; 

integer; 

text' {AUGMENTED PROGRAM FILE}; 
text {FILE OF EXCEPTED MODULE NAMES}; 
file of alfa {FILE OF ALL MODULE NAMES}; 
"^"namenode {LIST OF EXCEPTED MODULE NAMES}; 
modulecnt {RUNNING COUNT OF MODULES}; 



begin 

get(input); 

ch := input"; 

colcnt := colcnt + 1; 

while ( not eoln(input) and (colcnt > linelength)) do 

get(input) ; 
if eoln(input) then 
colcnt := 
end { NEXTCH }; 



procedure advance; 

begin 

if eoln(input) 
THen 

writeln(inter) 
else 

writednter, ch) ; 
nextch 
end {ADVANCE}; 



131 
132 
133 
134 
135 
136 
137 
138 
139 
140 
141 
142 
143 
144 
145 
146 
147 
143 
149 
150 
151 
152 
153 
154 
155 
156 
157 
158 
159 
160 
161 
162 
163 
164 
165 
166 
167 
168 
169 
170 
171 
172 

173 
174 
175 
176 
177 
173 
179 
130 
181 
132 
133 
184 
185 
186 
137 
138 
139 
190 
191 
192 
193 
194 
195 
196 



procedure readid; 

{ GLOBAL : CHBUF ,CH , IDENTIFIER , IDLEN , LASTIDLEN } 

begin { READID } 
idlen := 0; 
repeat 

if idlen < alfaleng then 
begin 

idlen := idlen + 1; 
chbufCidlen] := ch 
end {IF}; 
nextch 
{} until not (ch in ['a' .. 'z', '0' .. •9']); 
if idlen >= lastidlen 
then 

lastidlen := idlen 
else 

repeat 

chbuf [lastidlen] := ' '; 
lastidlen := lastidlen - 1 
until lastidlen = idlen; 
pack(chbuf , 1 , identifier) 
end {READID}; 



procedure writeid; 

var 

{ GLOBAL : CHBUF, IDLEN } 
i: integer; 

begin {WRITEID} 
i := 1; 
while i <= idlen d£ 

writednter, chbuf[i]); 
i := i + 1 



GO 

3> 



GO 



end {rfHILE} 
end {WRITEID}; 

procedure comment; 

begin 

advance; 
repeat 

wHTle ch <> '»' do 

advance; 
advance 
until ch = ' ) ' ; 
advance 
end {COMMENT}; 



procedure std comment; 

begin 

repeat 

advance 

until ch = ' }• ; 

advance 
end {3TDC0MMENT}; 



GO 



CD 

m 
en 



procedure scan; 



197 
198 
199 
200 
201 
202 
203 
204 
205 
206 
207 
208 
209 
210 
211 
212 
213 
214 

215 
216 
217 
213 
219 
220 
221 
222 
223 
224 
225 
226 
227 
228 
229 
230 
231 
232 
233 
234 
235 
236 
237 
238 
2 39 
240 
241 
242 
243 
244 
245 
246 
247 
248 
249 
250 
251 
252 
253 
254 
255 
256 
257 
258 
259 
260 
261 
262 



{ FIND NEXT IDENTIFIER (OR NUMBER IF READINGLABELS) . 
SKIP STRINGS AND COMMENTS. } 

label 
?T; 

{ GLOBAL : IDENTIFIER, CH , NUMBER, BADNAMES, READINGLABELS } 



function nokeyCid: alfa): boolean; 

var 

{ GLOBAL : SY,KEY } 
i, j: integer; 

begin { BINARY SEARCH } 
1 := beginsy; 
j := varsy; 
repeat 

sy := (i + j) div 2 ; 
if key[sy] <= id then 

i := sy + 1; 
if keyLsy] >= id then 
j := sy - 1; 
until i > j; 
nokey := keyCsy] <> id 
end { NOKEY }; 



begin I SCAN } 

while not eof(input) do 
begin 

while not eoln(input) do 
begin 

^7 ch = ' ' 
then 

advance 
else 



{} 



if ch in [ 'a' . . 'z' ] 
then 

begin 

readid; 

readinglabels := false; 

if nokey (identifier ) and not badnarnes 

then 

writeid 
else 

goto 21 { EXIT ON KEY OR EXCEPTED ID 
end {IF} 
else 

if ch in [ '0' . . '9'] 
then 

if readinglabels 
then 

begin 

read(number ) ; 
ch := inpuf; 
goto 21 { EXIT ON LABEL } 
end UF} 
else 



{} 



repeat 

advance 
until not (ch in ['a' 



'z' , 



'9']) 



263 
264 
265 
266 
267 
268 
269 
270 
271 
272 
273 
274 
275 
276 
277 
278 
279 
280 
231 
282 
233 
284 
285 
286 
237 
288 
289 
290 
291 
292 
293 
294 
295 
296 
297 
298 
299 
300 
301 
302 
303 
304 
305 
306 
307 
303 
309 
310 
311 
312 
313 
314 
315 
316 
317 
318 
319 
320 
321 
322 
323 
324 
325 
326 
327 
328 



begin 

repeat 

advance 
until ch = • " • ; 
advance 
end {IF} 
else 

U; ch = '(' 
then 

begin 

advance; 

jj; ch = «*' then 
comment 
end {IF} 
else 

if ch = •{' 
THen 

stdcomment 
else 

advance 



GO 
<— > 






end {WHILE}; 
writeln(inter) ; 
nextch 
end {WHILE}; 



21: 

end { SCAN 



procedure complmoduledastl: labelptr); 

{ PROCESS THE BLOCK OF A PROGRAM, PROCEDURE, OR FUNCTION TO FIND 
THE APPROPRIATE CODE INSERTION POINTS. LASTL IS THE HEAD OF THE 
LIST OF LABELS WHOSE SCOPE APPLIES TO THE BLOCK. COMPLMODULE 
MUST PARSE LABEL, VAR, PROCEDURE, AND FUNCTION DECLARATIONS, AS 
WELL AS GOTO STATEMENTS AND THE COMPOUND STATEMENT FORMIMG THE 
STATEMENT PART OF EACH MODULE. } 



'{ GLOBAL : IDENTIFIER , KEY , S^ , CH , READINGLABELS , NUMBER , COUNT } 

name; alfa; 

depth: integer; 

params: boolean; 

1: labelptr; 

gotolabel: .. 9999; 

looking: boolean; 

tag: modulecnt; 



procedure insertnewtext(code: codetype); 



se code of 
entry: 
begin 

write(inter, 'with tiTiing" do begin '); 

write(inter, ' 

write(inter, ' 

wr itelndnter , 
end {ENTRY}; 
exit: 
begin 

writelndnter , ' ; ' ) ; 

writednter, 'with timing" do 

write(inter, 'i:=', tag:4, '; 

writednter, ' t :=clock;m: = 1 ' {EXIT}); 

writelndnter, ' end ; put( timin 



oo 



'with ti-Tiing" do 
'i:=', tag: 4, ';' 
' t:=clock;in:=0' { 
' end; put(timini 



begin 

); 

ENTRY 

6);') 



}); 



begin 
); 

EXIT} 
g)'); 



3> 



to 



5^9 
330 
331 
332 
333 
334 
335 
336 
337 
333 
339 
340 
341 
342 
343 
344 
345 
346 
347 
343 
349 
350 
351 
352 
353 
354 
355 
356 
357 
358 
359 
360 
361 
362 
363 
364 
365 
366 
367 
368 
369 
370 
371 
372 
373 
374 
375 
376 
377 
378 
379 
380 
381 
332 
383 
384 
385 
386 
387 
388 
339 
390 
391 
392 
393 
394 



{} 



{} 



end I EXIT 1; 
gotoentry : 

begin 

wr iteCinter , 
wr iteCinter , 
wr iteCinter , 
wr itelnCinter , 

end {GOTOENTRY}; 
declare: 

begin 

writelnCinter , 



'with timing'' do begin '); 

'i:=', l".declaredin:4 , ';' 

't:=clock;fn:=2' {GOTOENTRY] 

end;put(timing); ' ); 



^.•^ , ' var ' ) ; 

wr iteCinter, 'timing; file of packed record '); 
writeCinter, • i :0. .2000; ' ) ; 
writeCinter, ' t:0 . .99999999; ') ; 
writeCinter, 'iti:0..2'); 
writelnCinter, ' end;'); 
end {DECLARE} 
end { CASE CODE OF } 
end { INSERTMEWTEXT }; 



function narneok: boolean; 

{ CHECK PROCEDURE OR FUNCTION NAME AGAINST LIST OF NAi^ES TO BE 
EXCLUDED. } 



{ GLOBAL : BADLIST,NAME } 
n; ^ namenode; 
looking: boolean; 

begin { NAHEOK } 
n := badlist; 
looking := true; 
while Cn <> nil ) and looking do 
begin 

looking := n'^.name <> name; 
n := n^.link 
end {WHILE}; 
narneok := looking 
end {NAMEOK}; 



begin {COMPLMODULE} 

while not Cch^ilt'a' •• ' z* 3 ) do 
if ch = 'C 
then 

begin 

advance; 

if ch = '*' then 
comment 
end 
else 

if ch = •{' 
then 

std comment 
else 

advance; 
read id; 

name := identifier; 
writeid; 
tag := count; 
pararas := false; 

while not params and Cch <> ' ; ' ) do 
if ch = 'C 
then 



395 
396 
397 
398 
399 
400 
401 
402 
403 
404 
405 
406 
407 
408 
409 
410 
411 
412 

413 
414 
415 
416 
417 
413 
419 
420 
421 
422 
423 
424 
425 
426 
427 
423 
429 
430 

431 
432 

433 { 

434 { 

435 { 

436 { 
437 
438 
439 
440 
441 
442 
443 
444 
445 
446 
447 

4 43 
449 
450 
451 
452 
453 
454 
455 
456 
457 
453 
459 
llf\0 



begin 

advance; 
iX ch = •»' 
then 

comment 
else 

pararas := true 
end {IF} 
else 

if ch = '{' 
then 

stdcomment 
else 

advance; 
if params 
then 

while ch <> ' ) • do { READ THROUGH PARAMETER LIST } 
if ch = '{' 
then 

stdcomment 
else 

if ch = ♦ C 
TEen 



-o 

CO 

3> 



oo 



advance; 

if ch = '»' then 
comment 
end {IF} 
else 

advance; 
if tag = 1 { MAIN PROGRAM } 
then 

writeCinter, ', timing)') 
else 

writeCinter, ch) ; 
nextch; 
scan; 

} IX sy _in [forwardsy, externsy, fortransy] 

} then 

} writeid 

} else 

begin 

count := count + 1 ; 
if count = maxraodules then 
begin 

writelnC' *too many procedures and', 

' functions to augment.'); 
goto 13 
end ; 
writeCinter2, name); 

if sy = labelsy { LABEL DECLARATION } 
"tKen 

begin { READ LOCAL LABELS } 
writeid; 

readinglabels := true; 
scan; 
repeat 

newCl) ; 

l^.labl := number; 
I'.declaredin := tag; 
writeCinter, number: 1); 
l^.next := lastl; 
lastl := 1; 
scan 
until not readinglabels 
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end IIF); 

while sy in [casesy, endsy] do { TYPE DECLARATION } 
begin 

wr iteid ; 
scan 
end {WHILE}; 
U; tag = 1 { MAIN PROGRAM } 
then 

insertnewtextC declare) 
else 

if not (sy in [beginsy, funcsy, procsy]) then 
writeid; 

if sy = varsy 
then 

scan; 

while sy in [casesy, endsy] do 

Fegin T"CASESY, ENDSY IN A¥~AN0NYM0US TYPE } 
writeid; 
scan 
end {WHILE} 
end {IFTT 

while sy i_n [funcsy, procsy] do 
begin 

writeid; 

coinplinodule(lastl) 
end {WHILE}; 

ij; sy = beginsy { STATEMENT PART } 
then 

begin 

depth := 1 ; 

writeid; 

iX tag = 1 { MAIN PROGRAM } 

then 

wr itelnCinter , ' rewriteC timing) ;' ) 
else 

wr itelnCinter ) ; 
if natneok then 

insertnewtextC entry) 
end {IF} 
else 

begin 

writelnC' *' 'begin'' expected.'); 
goto 13 
end {ELSE}; 

repeat { LOOK FOR LAST ENDSY } 
scan; 

U[ sy = gotosy 
then 

begin { CHECK AGAINST LOCAL LABELS } 
readinglabels := true; 
scan; 

gotolabel := number; 
readinglabels := false; 
looking := true; 
1 := lastl; 

while (1 <> nil ) and looking do 
if I'.labl = gotolabel 
then 

looking := false 
else 
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1 := l^.next; 
if looking 
then 

begin 



writelnC' *undecl3red label ', gotolabel: 1); 
goto 13 
end {IF} 
else 

begin 

if 1" .declaredin <> tag then 
begin { EXIT GOTO } 

writelnCinter , 'begin'); 
if nameok then 

insertnewtextCgotoentry) 
end {IF}; 
wr iteCinter, 'goto ', gotolabel: 1); 
if I'.declaredin <> tag then 
writelnCinter, ' end') 
end {ELSE} 
end {IFF" 
else 

i_f sy In [beginsy, casesy] 
then 

begin 

depth : = depth + 1 ; 
writeid 
end {IF} 
else 

if sy = endsy 
then 

begin 

depth : = depth - 1 ; 
if depth <> then 
writeid 
end {IF} 
else 

begin 

writelnC' *''end'' expected.'); 
goto 13 
end {ELSE} 
until depth = 0; 
if nameok then 

insertnewtextCexit); 
writelnCinter, 'end'); 
end {ELSE}; 
scan 
end {COMPLMODULE}; 



procedure readbadnames; 

var 

{ GLOBAL : 3ADLIST, CHBUF } 
n: " namenode; 
i: 1 . . alfaleng; 



begin { READBADNAMES } 

writelnC'the following procedures will not be augmented' :50); 

writeln; 

repeat 

newCn) ; 

for i := 1 to alfaleng do 
if eolnCexcept) 
then 

chbuf[i] := ' ' 
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else 

readCexcept, chbufCi]); 
readln(except) ; 
pack(chbuf, 1, n'^.name); 
n^.link := badlist; 
badlist := n; 
writeln(n".narne :25); 
writeln 
until eof(except) 
end { READBADNAMES }; 



egin { MAIN PROGRAM } 
rewrite(inter) ; 
rewr ite(inter2) ; 
reset(except) ; 
ch := input''; 
count : = 1 ; 
colcnt : = 1 ; 
linelength ;= Umax; 
lastidlen := alfaleng; 
linelimitC inter , maxint); 
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keyCbeginsy ] := 'begin 
keyCcasesy ] := 'case 
keyCendsy ] := 'end 
{} keyCexternsy ] := 'extern 
} key[fortransy] := 'fortran 
} keyCforwardsy] := 'forward 
keyCfuncsy ] := 'function 
keyCgotosy ] := 'goto 
keyClabelsy ] := 'label 
keyCprocsy 3 := 'procedure 
keyCprogramsy], := 'program 
keyCvarsy ] := 'var 
badlist := nil; 
if not eof(except) then 

readbadnaraes; 
scan; 

readinglabels := false; 
ij^ sy = prograrasy 
then 

begin 

writeCinter, 'program'); 
complmodule( nil ) 
end {IF} 
else 

writelnC' *' 'program'' expected.'); 
3: 

nd { AUGMENT }. 
* ANALYZE - ANALYZE AND SUMMARIZE EXECUTION TIME 

PERFORMANCE MEASUREMENTS FROM AN AUGMENTED 
PASCAL PROGRAM. 

S. MATWIN AND 

M. MISSALA 1975. 

POLISH ACADEMY OF SCIENCES COMPUTER CENTRE. 

PKIN, WARSAW POLAND. 

MODIFIED, GENERALIZED, AND RENAMED 

FROM "PRINRES" TO "ANALYZE" BY: 

A. B. MICKEL 77/11/18. 

H. U. RUBENSTEIN 77/05/15. 

UNIVERSITY OF MINNESOTA COMPUTER CENTER 

MINNEAPOLIS, MN 55455 USA. 

THE NAMES AND ORGANIZATIONS GIVEN HERE MUST NOT BE 
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DELETED IN ANY USE OF THIS PROGRAM. 

SEE THE PTOOLS WRITEUP (UNDER MEASURE) FOR 
EXTERNAL DOCUMENTATION. 



ANALYZE (INTERNAL DOCUMENTATION). 

ANALYZE READS TWO FILES. INTER2 IS THE FILE CONTAINING 
THE MODULE (PROCEDURE AND FUNCTION) NAMES WHICH ARE USED 
WHEN THE RESULTS ARE SORTED AND WRITTEN OUT. TIMING IS 
THE FILE CONTAINING THE EXECUTION TRACE OF THE PROGRAM 
BEING MONITORED. 

WITHIN ANALYZE, THE PROCEDURE NAMED PROCESSBODY DOES THE 
ACTUAL ANALYSIS BY DETERMINING EVERY TIME INTERVAL: 

TIMECEXIT] - TIMECENTRY3. 

EVERY GOTOEXIT FROM A PROCEDURE IS CONSIDERED TO BE A 
SPECIAL KIND OF PROCEDURE ENTRY, SO THAT ALL PROCEDURES 
WHICH, UP TO THAT TIME HAVE BEEN ENTERED BUT NOT NORMALLY 
EXITED, ARE ALL EXITED BY THE GOTOENTRY. SEE THE COMPANION 
PROGRAM CALLED AUGMENT. 



{$R-,T-,P-,U+} 

program analyze(output, inter2, timing); 

label 
13; 

const 

alfaleng = 10; 
maxnames = 2000; 

type 

alfa = packed array [1 .. alfaleng] of char; 
tagrange = 1 .. maxnames; 
measurement = packed record 

tag: tagrange; 
time: .. 99999999; 
mark: (entry, exit, gotoentry) 
end; 
counter = record 

count: integer; 
name: alfa; 
timespent: integer 
end; 



timing: file of measurement; 

inter2: file oT alfa; 

modules: arrayT tagrange] of counter; 
maxtag, 

tag: tagrange; 

progtime: integer; 
totaltime, 

totalcalls: integer; 



GO 

3> 



GO 



CO 



3> 
CD 
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CD 



procedure sort(fflin, max: tagrange); 
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{ QUICKSORT WITH BOUNDED RECURSION DEPTH } 
{ REQUIRES MIN <= MAX } 



low , 

high: integer; 

midkey: alfa; 

temp: counter; 

begin 

repeat {PICK SPLIT POINT} 

midkey := modulesC (min ■♦- max) div 2]. name; 
low := min; 
high := max; 
repeat {PARTITION} 

while modulesLlow] .name < midkey do 

Tow : = low + 1 ; 
while modulesChigh] .name > midkey doi 

high := high - 1 ; 
if low <= high then 
begin 

temp := modulesClow] ; 
modulesLlow] := modulesLhigh] ; 
modules[high] := temp; 
low : = low + 1 ; 
high := high - 1 
end ; 
until low > high; 

{RECURSIVELY SORT SHORTER SUB-SEGMENT} 

if high - min < max - low 

then 

begin 

if min < high then 
sort(min, high) ; 
min := low 
end 
else 

begin 

if low < max then 
sortClow, max) ; 
max := high 
end 
until max <= min 
end {SORT} ; 



procedure processbody; 

{ PROCESS TIMING FILE OF DYNAMIC MEASUREMENTS. } 



moduletag: tagrange; 
moduletime: integer; 



begin 
mod 
mod 
get 
whi 



uletag := timing". tag; 

uletirae := - timing". time; 

(timing) ; 

le timing". mark = entry do 

begin 

moduletime := moduletime + timing". time; 

processbody; 

moduletime := moduletime - timing" .time; 

if (timing" .mark = gotoentry) <= (timing" 



.tag = moduletag) 



then { ONLY ADVANCE THE TIMING FILE IF A GOTOENTRY 
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IS NOT ENCOUNTERED OR IF A GOTOENTRY IS 
ENCOUNTERED INTO THE CURRENT MODULE. } 
get(timing) 
end; 
moduletime := moduletime + timing" .time; 
totalcalls := totalcalls + 1; 
with modulesCmoduletag] do 
^egin 

count : = count + 1 ; 
timespent := timespent + moduletime 
end 
end {PROCESSBODY}; 

begin {MAIN PROGRAM} 
reset(inter2) ; 
tag := 1; 

while not eof(inter2) do 
begin 

with modulesLtag] do 
begin 

read(inter2, name); 
count := 0; 
timespent := 0; 
end ; 
tag := tag + 1 
end; 
maxtag : = tag - 1 ; 
reset(tiraing) ; 
if eof(timing) then 
begin 

writeln(' ^timing file empty.'); 
goto 13 
end; 
progtime := timing". time; 
totalcalls := 0; 

processbody; 

totaltime := timing". time - progtime; 

page(output) ; 

writeln; 

writeln; 

writeln(' performance measurement summary for pascal program: ', 

modulesC 1 ] .name, * . * ) ; 
writeln; 

writeln( 'execution time': 62); 
writeln( 'calls' : 27, '(milliseconds)': 35); 
writeln( 'module' : 9, 'times': 13, 'percent': 11, 'average': 15, 

'module': 10, 'percent': 11); 
writelnCname': 8, 'called': 15, 'of total': 11, 'per call': 15, 

'total' : 8, 'of total' : 13); 
writelnC ', ' ': 12, ' ': 11, 

t .: 15, t ,. 9^ . ,. ^2); 

if maxtag > 1 then 
sort( 1 , maxtag) ; 
for tag := 1 _to maxtag do 
with modulesLtag] do 
begin 

write(name: 11, count: 12, 

((count « 100) / totalcalls): 11:3); 
if count = 
then 

writeC ': 15) 

else 

write( (timespent / count): 15:2); 



GO 



GO 



OO 



-a 



216 wr itelnCtirnespent: 9, 

217 ((timespent * 100) / totaltime): 12:3) 
213 end ; 

219 writelnC ==========», '======': 12, •========': 11, 

220 •========': 15, '======': 9, '========»: 12); 

221 writelnC 'totals' : 9, totalcalls: 14, '100.000': 11, 

222 (totaltime / totalcalls): 15:2, totaltime: 9, '100.000': 12); 

223 13: 

224 end {ANALYZE}. 
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PROGRAMS 



1 Pn'ntme 



(* Nearly ewery programming language has to have a program which can reproduce its source 
text as output. In 1976, Pascal enthusiast, John Strait of the University of Minnesota, 
(who incidentally maintains the CDC-6000 compiler for the world), wrote such a program, 
and it is presented below. When Urs Ammann, of E.T.H., Zurich, (who incidentally 
authored the CDC-6000 compiler), saw this program, he said he had written a shorter 
one using a case statement. We have not seen it, but we would like to. *) 

PROGRAM PRINTME(OUTPUT) ; 

(*JPS 76/05/26.*) 
CONST FIRST4ALF = 9; 

SECONDHALF = 10; 

LENGTH = 22; 

Q = "" ; 

VAR I, J: INTEGER; 
IMAGE: ARRAY[0. .LENGTH] OF 
PACKED ARRAY [1.. 40] OF CHAR; 
BEGIN (* PRINTME *) 
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'PROGRAM PRINTME(OUTPUT) ; 
' (*JPS 76/05/26.*) 
'CONST FIRSTHALF = 9; 
' SECONDHALF = 10; 
' LENGTH = 22; 

' Q = ; 

'VAR I, J: INTEGER; 

' IMAGE: ARRAY[0. .LENGTH] OF 

' PACKED ARRAY[1..40] OF CHAR; 

'BEGIN (* PRINTME *) 

'FOR I := TO FIRSTHALF DO 

' WRITELN(IMAGE[I] ) ; 

'FOR I := TO LENGTH DO 

' BEGIN WRITE("IMAGE[" ,1: 2,"] : 

' FOR J := 1 TO 40 DO 

' IF IMAGE [I] [J] = Q 

THEN WRITE(Q,Q) 

ELSE WRITE(IMAGE[I] [J] ) ; 
' WRITELN(Q,"; " ) 
' END; 

'FOR I := SECONDHALF TO LENGTH DO 
' WRITELN(IMAGE[I] ) 
'END (*PRINTME*). 
FIRSTHALF DO 



",q); 



IMAGE [2 2] 

FOR I := TO 

WRITELN(IMAGE[I] ); 
FOR I := TO LENGTH DO 
BEGIN WRITE('IMAGE[ ',1:2,'] 
FOR J := 1 TO 40 DO 
IF IMAGE [I] [J] = Q 
THEN WRITE(Q,Q), 
ELSE WRITE(IMAGE[I] [J] ) ; 
WRITELN(Q,' ; ' ) 
END; 
FOR I := SECONDHALF TO LENGTH 

WRITELN(IMAGE[I] ) 
END (*PRINTME*). 



,Q); 



Extensions to PASCAL for Separate Compilation 

Richard J. LeBlanc 

School of Information and Computer Science 

Georgia Institute of Technology 

Atlanta, Georgia 30332 



The lack of features in PASCAL to allow procedures 
and functions to be compiled separately can be of 
considerable inconvenience in the development of large 
programs. This weakness is particularly evident when 
modifications are being made only to limited parts of a 
program. Modifications of this sort are common, for 
example, in the maintenance or extension of a PASCAL 
compiler . 

The extensions described below allow the creation 
of a global environment, separate compilation of 
routines using that environment, and additions to the 
environment without requiring recompilation of existing 
routines and declarations. Four kinds of modules are 
recognized to implement these features: 



modules are used to create 



1) Declaration 
vironment . 

Routine modules are used to provide 
routines declared in an environment. 

Environment extension modules are used to make ex- 
tensions to an environment. 
Main program modules are used to compile 
program body. 



the bodies of 



the main 



Declara t ion modules 
<declaration module> ::= 

<declaration heading> <declaration block> . 
<declaration heading> : := 

declarations (<file identifier>) ; 
<doclaration block> : := <constant definition part> 

<type definition part> <variable declaration part> 

<routine heading list> 
<routine heading list> : := <empty> I 

<routine heading> {, <routine heading>} 
<routine heading> ::= <procedure heading> I 

<function heading> 

Within the module may be declarations of constants, 
types and variables just as in a standard main program. 
Following these declarations come the headings of 
routines that are to be part of the environment. These 
headings are identical to the headings in normal routine 
declarations . 

Any identifier defined in a declaration module may 
be referenced in any other module compiled using the en- 
vironment created from the declarations. This mechanism 
allows routines compiled separately to call each other 
and to use the same global constants, types and 
variables. Compilation of a declaration module creates 
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a description of an environment. This description is 
used to do all type checking at compile-time , just as if 
separately compiled routines had been compiled as a 
standard program. 



Routine modules 
<routine module> ::= 

<routine module head> <routine module body> . 
<routine module head> : := <environment head> routines 

( <identifier> {, < identifier > } ) ; 
<environment head> : := environment (<file identifier>) ; 
<routine module block> : := <constant definition part> 

<type definition part> <variable declaration part> 

<routinG declaration part> 
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A routine module defines a new name scope, so 
identifiers used in the global environment may be 
redefined within a module. When a routine declared in 
the global environment is defined in a routine module, 
the declaration of its parameters is repeated and the 
types must match those specified in the environment 
declaration. (Since the parameter names are not 
relevant to type checking, they need not match those in 
the declaration.) 



Environment extension modules 
<environment extension module> ::= 

<extend heading> <declaration block> . 
<extend heading> ::= 

extend (<file identifier>, <new file identifier>) ; 

Environment extension modules may add any kind of 
declaration to the environment, but cannot change any 
existing ones. The environment description from the old 
environment file is expanded to describe the extended 
environment and is written as the new environment file. 



Main program modules 
<main module> ::= 

<environment head> <program heading> <block> . 

Main program modules look exactly like standard 
PASCAL programs except that the heading is prefixed by 
an environment heading to supply an environment file 
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specification. If any routine modules have been com- 
piled in environments produced by extending earlier en- 
vironment declarations, the main program module must be 
compiled in the last of the extended environments. Only 
a linear succession of environments may be used to com- 
pile the modules that make up a program. 
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What Are Pascal's Design Goals? 

Robert D. Vavra 
y^arch 13, 1978 

As a long-time reader of Pascal News (PN), I have enjoyed the many 
articles in which people have discussed various features which could 
be added to Pascal, but I have been unable to take much of the 
discussion seriously. In arguing for or against some particular 
feature, writers have rarely invoked Pascal's design goals in support 
of their arguments. Such failure to build a proper foundation for 
one's arguments wight be acceptable in casual conversation, but not in 
a serious discussion. 

If a discussion about a language feature is to be taken seriously (by 
me, at least), the writer must demonstrate that it is firmly based on 
Pascal's design goals. It is not enough to support a proposed feature 
by saying that it is easy to use or implement, nor to reject a 
proposed feature by saying that it is only a "favourite feature". A 
writer should weigh a proposed feature against each of Pascal's design 
goals by pointing out which goals favor it and which do not, and 
should discuss why the tradeoff is desirable. 

All of this presupposes that Pasca I's des ign goals are well-understood 
and generally accepted. In fact, Pascal's design goals are rarely 
mentioned in PN, so I stspect that they are not well-understood. 
Further, I think that much of the debate over various language 
features is really a debate over what Pascal's design goals should be. 
This article attempts tc remedy this situation by summarizing what 
Wirth's design goals for Pascal originally were, and by starting a 
discussion of what Pascal's design goals should now be. 

In both the original anc revised reports C1,23, Wirth's stated design 
goals are suitably modest: 

* To make available a language suitable to teach programming as a 
systematic discipline. 

* To allow development of implementations which are both reliable 
and ef f i c ient • 

In E33, Wirth stated the following design goals: 

* To make available a notation in which the fundamental concepts 
and structures of programming a r e e xpress ib le in a systematic, 
precise, and appropriate way. 

* To make available a notation which takes into account the various 
new insights concerning systematic methods of program 

deve lopment . 

To demonstrate that a language with a rich set of flexible data 
and program structtring facilities can be implemented by an 
efficient and moderately sized compiler. 

* To demonstrate that the use of a mac ^i^e"^ ndepende^ t language 
kith flexible data and program structures for the description of 

a compiler leads tc an increase of its readability, ver i f iabi I i t y 
and consequently its reliability, and that this gain need not be 
offset by any loss in efficiency. 

* To gain wore insight into the methods of organizing large 
programs and managing software projects. 

* To obtain a home-made tool which can easily be adapted to other 
needs. 



In CA3, Wirth stated the following design goats: 

* To permit clarity and rigour of description by using a small 
number of fundamental concepts, thereby making program 
verification easier. 

* To have a wide ranee of applicability through proximity to actual 
computer structure, rather than through a host of features 
collected from various fields of usage. 

* To promote both compile- and run-time efficiency by omitting 
features which require multi-pass compilation or elaborate 
run-time support. 

* To promote reliability and efficiency of compilers by providing 
a language which is simply and regularly structured, thereby 
allowing the compilers to be simply and regularly structured. 

* To promote machine independence (portability) by extending the 
definitional capabilities of the language to such a degree of 
generality that machine dependent entities (types and operations) 
«ray appear as special cases selectable by means of predefined 
names, and whose use presumably enhances the efficiency of 
programs executed en the particular system in which they are 

def ined. 

In C53, Hoare and Wirth summarize all these goals as: 

* To make available a general purpose language efficiently 
impUmentable on many computers and sufficiently flexible to be 
able to serve in many areas of application. 

Interested readers can find further details in each of the referenced 

papers . 

As a starting point for a discussion of what Pascal's design goals 
Should now be, I suggest the following list: 



Gene ra I 
purpose 



Int r odu c t or y 



LOW level 



Pascal should be usable in almost any application 
area or almost any computer system. There should be 
reasonably easy ways to manipulate both numeric and 
non-nuireric data, to make use of pre-existing 
software subsystems (either in libraries or in the 
operating system), and to implement new 
general-purpose software subsystems in Pascal. 



Pascal should be usable by beginning programmers in 
an introductory programming course. It should be 
possible for them to write simple programs without 
needing detailed knowledge of large portions of the 
language, e.g. I/O. 



Pascal's features should be close to those 
supported by current computer systems. Any 
higher-level abstractions (e.g. lists, strings, 
i/o) should be supported by writing new types and 
procedures in Pascal. 
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Small 



Syst ema t ic 



Software written in Pascal should be reasonaoly 
easy tc move from one computer system to another. 
It should be easy for programmers to isolate 
implementation dependencies in a few places within 
prograrrs. There should be a minimal number of 
situations in which the actions of a program are 
"undefined" or "defineo by the implementation". 



Pascal should include a minimal number of 
fundamental concepts. 



Pascal should encourage the programmer think 
systematically by allowing him or her to 
concentrate on a small section of the program at a 
time. Fa seal should minimize the number of special 
rules which must be learned, instead relying on 
general rules which apply in all situations. 



Obviouslyt ff'uch more needs to be said about Pascal's design goals. For 
starters, important design goals may need to be added (e.g. 
reliability, replacement for Fortran). Additionally, each of the 
design goals needs to be more fully explained (e.g. what does 
"thinking systematically" really mean). Finally, the implications of 
the entire set of design goals need to be explored (e.g. are the 
present extension mechanisms powerful enough to allow the language to 
be general purpose, low level, ctnd small?). 

I hope to find the time to write more about Pascal's design goals, and 
I encourage others (especially those who are proposing language 
features) to do the same. I look forward to a continuing dialogue in 
PN on this important topic. 



PASCAL ENVIRONMENT IMTERFACfi 

T. Noodt 
University of Oslo 



9.2 ^J}jJl%^ „ comments 

I am at present working on a Pascal implementation for the 
Nord 10, running an interactively oriented operating system. 
(The Nord is a 16-bit Norwegian-made computer. It comes in two 
variants with 48-bit and 32-bit reals, respectively.) The 
Pascal Report does not say too much about how to interface a 
compiler to a computer system and its users. To further 
complicate matters, what it does say about this relates to a 
batch system, and is worthless or unusable in an interactive 
system. 

1 think that the design of the Pascal environment is fairly 
important, and that a certain unification would be of value. 
Below I have schetched a few thoughts about this, and also 
make some proposals. 

Why bother 

A language is often judged on the way a particular 
implementation interfaces to iis environment, i.e. 

1) what tools are available to a user for the construction, 
compilation, and execution of a program, and 

2) what are the interfaces between the implementation and 
other systems on the computer (particularly the operating 
system) . 
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Examples of such interfaces are: - What the available options 
are, and in what way they can be set or reset. - How a 
specific file is associated with a file name within a program. 

Pascal implementors and fans have chosen to step off the 
FORTRAN, BASIC, and PL/I highways to enjoy the much nicer view 
from the Pascal path. The implementors being such rugged 
individualists, there probably are as many different Pascal 
environment interfaces as there are Pascal implementations. 
Implementors are inventing and re-inventing interface 
features, giving different names to the same feature, or 
implementing the same feature in a slightly different way. 

Since all the big computer vendors soon will become Pascalers 
(do you doubt it?) , the situation will become worse. In vendor 
A's Pascal implementation, all the extra-language "nice 
features" will be totally incompatible with those of vendor B. 
Goodbye portability. 
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So_what 

All Pascal implementations need a minimal environment 
interface, and often a broader interface is highly desirable. 
There is no reason why this interface should be a completely 
new one for every new implementation. A little effort can give 
a lot towards unification, at least in future implementations. 

I would like to see a discussion about what such an interface 

ought to contain, ending up with someone making a 

recommendation list of features which seem necessary or highly 
desirable, with the heading: 

If you want to include a feature from the list below in 
your Pascal implementation, it is recommended that you 
adhere to the specifications stated for that feature. 

To initiate a discussion about these matters, I will present 
my tentative list for the extra-language features in the 
Pascal implementation I am working on at present. 



Options 

Option 

L 

M 

Rn 
Sn 

T 



Effect 

List program 

List symbolic object code (MAC) 

Reals will occupy n words 

Sets will occupy n words 

Generate run-time test on 

indexing, sub-range assignments etc. 

Convert all lower-case letters 

outside strings to upper case 



Default 

on 

off 

3 



off 



Cond i t ional comp i lat ion 

The compiler will conditionally skip parts of the source text, 
depending on the value of flags which can be set by the user. 
Source lines containing commands to the compiler must have the 
character $ in position 1. 

flag -> identifier 
Command Effect 



$SET flag 
$RESET flag 
$IF flag 

$ELSE flag 

$END flag 



flag gets value t£ue 

flag gets value false 

Include succeeding source lines if 

flag is true 

End of $IF of same flag. 

Include succeeding lines if flag is false. 

End of $IF or $ELSE of same flag. 



A flag which has not been assigned a value, will have the 
value false . 

Mul t i pi e so urc e fil es 

The compiler command 

$INCLUDE filename 
will include the content of that file at this point in the 
source text. The command may be used recursively. 

Command _P£oce ssor 

The command processor is a part of the compiler which accepts 
commands specifying parameters for a compilation. 

SET flag 
RESET flag 

Set and reset conditional compilation flags. 

OPTIONS option-list 

Set or reset options according to option-list, which has 
the same syntax as if it appeared within a Pascal comment. 

COMPILE sourcefile, listfile, objectfile 

listfile and objectfile are optional. The L-option is 
turned off if listfile is left out. 

File _ac cess 

The procedure OPEN enables association between a specific file 
and a Pascal file variable at runtime. 

P£££^^.H£1 OPENCF- file type; NAME: string; 
var STATUS: integer) . . . 

F is associated with the file with name NAME. The file is 
opened, and status for this operation is left in STATUS. 
The parameters NAME and STATUS are optional. If NAME is 
not present, the system wil enquire the user to specify 
the file. If STATUS is not present and an error occurs, 
the job will be aborted if in batch mode or if NAME was 
specified, otherwise the user will be asked to respecify 
the file name. 

procedure CLOSE (F: file type) . . . 

The file is closed, and F is disassociated from the file. 

§^Hi^ ard procedures 

The following standard procedures will be implemented. 
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procedure TIME(var HOUR, MIN, SEC: integer) . . . 

procedure DATE(var YEAR, MONTH, DAY: integer) . . . 

function TUSED: real . . . 

(* gives accumulated CPU time in seconds *) 

Inter ac t ive pr og r ams 

Several difficult problems arise in the design and running of 
interactive programs. OPEN and CLOSE take care of run-time 
association of files. 

Another nasty problem is that of reading data from a terminal. 
If the data does not have the correct syntax, it is of course 
not acceptable to abort the program. The CERN Pascal 
implementation has solved this problem in the following 
manner : 

There is a standard procedure 

SETINTERACTIVE 
which when called, will make all error exits from READ save an 
error status instead of aborting the program. This status can 
be read with the function COMPLETION. 

Clos in g comments 

Some of the specifications above are vague, partly because I 
do not feel that a long, detailed document is necessary at 
this stage. Also, your own interpretation or evaluation of a 
feature may be as good, or better, than mine. 



SUBRANGES AND CONDITIONAL LOOPS 



*Judy M. Bishop 
Computer Science Division 
University of the Witwatersrand 
Johannesburg 
2001 SOUTH AFRICA 



The subrange facility in Pascal is an aid to runtime security 
for fixed bounaary constructs such as counting ( for ) loops and array 
subscripts. The relevant types can be precisely and naturally 
defined and the compiler can minimise the amount of runtime checking 
required. However, an index which increases under program control, 
as in a conditional ( while ) loop, presents a problem. This note 
discusses the problem and presents a solution in terms of a naming 
convention . 

THE PROBLEM 



Consider the definitions 

type index = min 
var i : index; 
and the conditional loop 



1 := min; 

while (i <= max) and condition do 

begin 

(* something *) 

i := succ (i) 
end; 



[Dl] 



[D2] 
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I invite criticism and 
described above. You are 
features. 



comments on 
also invited 



the features I have 
to add or subtract 



However, I am not looking for an environment interface list 
which is as long as possible. Think ecologically, and do not 
let the environment pollute Pascal! 



March 1978 
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If the condition remains true, an attempt will eventually be made to 
set i to succ (max) - a quite normal way of triggering the end of 
the loop. However, because i's type was precisely defined, 
succ (max) does not exist J Rewriting the loop with the tests at the 
end gives a similar error with respect to pred(min) , i.e. 

i := pred (min) ; 
repeat i := succ (i) ; 

(* something *) 
until (i = max) or condition; 

Even without a compiler or program verifier run, it is obvious 
that these loops are inconsistant with the definitions [Dl] . If the 
loop had only the test on i , then the for statement is the appro- 
priate construct and the undefined nature of the final value is taken 
care of by the compiler. At least, it should be, but only the B6700 
does this. According to Sale's Pascal Compatability Report, the 
various final values are 
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undefined - B6700 

max - CDC6000, Univac 1100 

succ Cmax) - Dec-10, ICL1900, ICL2900 

Do these options apply equally to suae? Like Sale, I think they 
should not: an implementation should have a detectable undefined 
value and suae (max) should yield it. This does not solve the 
original problem which was to allow a succ (max) for the purposes 
of controlling a loop. 

Typically, this is achieved by weakening the type definition 
to one of 



type index = min . . succmax; 
or type index = predmin . . max; 
°^ type index = predmin . . succmax; 



[p4l 



This compromise raises its own problem: the subscript type of a 
corresponding array declaration such as 

var a : array [index! of item; 

expects the original index type as defined in JDl] and not one of 
[p4j's extended ones. 

A SOLUTION 

In teaching programming to undergraduate students at 
Southampton, we made subranges "compulsory". (This can be done 
by omitting to mention the predefined types integer and real.) We 
were also blessed with a security-conscious compiler. In order to 
avoid untold "out of range" errors and general disillusionment 
in Pascal, we developed the following convention: 

1. Subranges are defined over the genuine, natural range of elements, 
typically that which would be used as an array subscript. 

E.g. 

type months = 1 .. 12; [ds] 

money = minint . . maxint; 

var balances : array; [months] of money; 

2. If an index is required for this subrange, its type is given 
the same name but prefixed by x- (for "extra") or z- (for 
"zero") . 

E.g. 

const dec = 12; [bs] 

type xindex = min . . succmax 

xmonths = 1 . . 13; 

zmonths = O . . dec; 

3. For an ennumerated type, the extra or zero element in the list 
is named according to the type with the appropriate prefix. 
E.g. 

type xmonths = (jan, feb, mar, apr, may, jun, [bv] 

Jul, aug, Sep, oct, nov, dec, extramonth) ; 

months = jan .. dec; 



function deficit (since : months) : boolean; 
var m : xmonths; negative : boolean; 
begin 

negative := false; m := since; 
while not negative and (m <= dec) do 
begin 

negative := balances [m] < O; 
m := succ (m) 
end ; 

deficit := negative 
end; (* deficit *) 

Deficit will work with the definitions in [dsJ plus either those in 
[Db] or [d7] . It could be called by 
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or by 



if deficit ( (*since the*) 6 (*th month*) ) then 
if deficit ((*in*) dec) ) then ... 



This is made possible by keeping max (in this case dec) symbolic and 
by making use of succ instead of +1 . In all compilers known 
to nP , succ (m) is equivalent to m+1 , that is , it does not invoke 
a function call. 



COMMENTS 

1. Single letter prefixes do, admittedly, hinder readability, but 
were chosen so as to impinge the least on the length of the 
original name. 

2. A single letter was not considered necessary for the dummy 
ennumerated element since clashes here would be few. 

3. The possibility exists for relating a subrange with its 
extensions in a more formal way. Language designers and 
pedagogues may care to investigate this . 

ACKNOWLEDGEMENTS 
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one type as the union of all possible variations, should be 
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solution to be both workable and effective. 



The Pascal Compatability Report can be obtained from 

Professor A.H.J. Sale 
Information Science 
University of Tasmania 
Box 252C 
Hobart 
Tasmania 7001. 
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A feuj proposed Deletions 



John Nagle 

Information Systems Design 
3205 Coronado Drive 
Santa Clara, CA 95051 



(408) -249-8 100 



Pascal have been 

propose a f e ui 

With the goal in 

useful language 



Since q,uite a number of extensions to 
proposed/ I thought that it would be desirable to 
deletions to keep the size of the language down, 
mind of keeping Pascal a simple. elegant/ and 
requiring a minimum of run-time machinery/ I propose a few simple 
changes in the direction of simplicity. 



Get rid of GOTO and LABEL 



register allocation in the compiler/ 
existing correct programs. 



and is fully compatible with 



Get rid of the CASE statement ambiguity 



The action of the CASE statement when the CASE selector is out 
of range is 'undefined'. In one implementation/ nothing happens 
in such cases. In another/ the error is always detected and 
fatal. One of these two actions should be made standard. I would 
go for making it fatal (and perhaps installing a case name of 
'other' to allow the program to capture these cases). 



5. Get rid of 'column 1 forms control' 



CO 

=54: 



Need I say more"? 



Get rid of the FORWARD declaration 



FORWARD declaration is a means by which a simple one-pass 
can find out about calls to procedures not yet defined, 
e compiler can perfectly well figure this out under its 
r by capturing the procedure definition at its first call/ 
Id not need to saddle the programmer with this 
bility. At the end of the com.pilation we can list all 
d procedures. This implementation has the additional 
e that the compiler will not complain so much when wa 
programs which avQ not yet complete/ yet will even 
ck the calls of unwritten procedures for compatibility. 
in keeping with the 'top -down' coding philosophy. 



Get rid of the 'FOR loop variable problem' 



When we get rid of GOTO/ we simplify the semantics of the FOR 
loop by guaranteeing that the index variable of the FOR is always 
meaningless outside of the loop. Given this simplification/ why 
not simply dtsclave the FOR index variable automatically at the FOR 
statement AS LOCAL TO THE LOOP. The programmer need not declare 
it at ail/ nor should he, since it has no meaning outside the 
loop. The type of the variable is implicit in the type of the 
value assigned to it in the FOR statement. This gets rid of the 
ambiguity associated with the present definition/ simplifies 
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I am aware that this is not a part of the language but of an 
implementation. However/ it is a very undesirable extension as it 
builds an implementation dependence into programs unnecessarily. 
The procedure 'page(<f i le^^) ' is defined as indicating page 
ejection. I suggest we use it. Blank lines may be inserted fay 
calls to WRITELN without parameters. If it is desirable to handle 
the printing of blank lines in some special way to improve 
printing speed/ the WRITE routine should take care of thes detail 
by itself. 



Get rid of the proposed 'formatted read' 
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Open Forum for Members 

The University of Tasmania 




Postal Address: Box 252C, G.P.O., Hobart, Tasmania, Australia 7001 
Telephone: 23 0561. Cables 'Tasuni' Telex: 58150 UNTAS 



Mr. A. Mickel, 
Editor, PASCAL News, 
Computing Centre, 
University of Minnesota, 
Minneapolis, Minnesota 
U.S.A. 



Dear Sir, 



18th January, 1978 



PASCAL in Australia 

May I clarify a few points that have arisen from my letters in #9/10? 
Firstly the cost of Australian subscription has been criticised for its 
size ($A10.00) against the US fee ($US4.00). Our original budgetting was 
based on the following quoted figures: 



Cost/copy (based on issue #8) 
Postage/copy (in Australia) 



$2.80 

.70 (higher in NZ, Malaysia) 



3.50 



I suspected the cost/copy to be high, and we struck a rate of $2.50/copy as 
reasonable, giving a subscription of $10 (4 copies per year). This makes 
no allowance for othermail (reminders), the necessity to overprint to fill 
back-orders and possible sui-plus stock, and higher postage to overseas 
countries. It must be remembered that the print run in Australia is small, 
and the postage rates are simply fiendish. 

Subsequently, issues 9/10 have been coalesced, and by the time next year 
comes we shall know better what it really costs. I hope it is less. 
Preliminary revisions of the costs have shown cost/copy at about $1.00 and 
postage in Australia has dropped to 60c, making a fee of $7.00 possible. 
I'll give you a figure for 1978/9 after we have processed #11 . 

Tiie second point I have been taken to task over is a statement of mine that 
our first-year course switch to PASCAL was "a first for reactionary Australia" 
Since this seems to have been misunderstood, PASCAL News readers may be 
interested to know that PASCAL has been in use in CDC universities for some 
time, notably the Universities of Adelaide, Sydney, New South Wales (and 
Melbourne) . In some cases as an introductory language, in others as a later 
language. 

However, in none of these, nor in any of the other universities that I know, 
has the combination of a full undergraduate first-year course combined with 
the use of PASCAL as a first language . However, I don't know everything that 
goes on in all of the 20 universities spread over the continent, so I apolo- 
gize if I'm wrong. My clear impression is that FORTRAN still dominates the 
Australian scene, with COBOL and BASIC hovering around as well. 

Yours sincerely. 



^M^Si^ 



Arthur Sale, 

Professor of Information Science. 
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riferimenti da citare nella risposta 



026/77/0343/GS/ls 



Bologna II/II/1977 



Dear Mr. Mickel, 

I wish to submit a few considerations to the Forum of 
PUG members and PASCAL implement ers: 

Prologue ; 

"The new language PASCAL is my own favourite prograjmning language, but 
only time will tell if it can fall beneath its academic roots" 

"Teaching the fatal desease" - R. Holt - SIGPLAN Notice (lay 1973), 
I work in a Software Consulting Agency that deals with the following 
main subjects: 

- mathematical modelsj 

- management information systems; 
basic software and process control. 

Our applications must work on user's defined environments so we design 
ajid code programs for different computers. I emphasize: we design and co 
de, we do not teach programming. 

Aim : 

We think that PASCAL is a very good language (we use it, as design tool, 
since 1972, and as coding language since 1975) but we also think that a 
few PASCAL features ought to be improved and a few ones ought to be in- 
troduced, on our opinion, in order to provide a good use in commercial 
applications or, that is almost the same, in day-to-day programming. 
"You Know that Qofo of commercial application programming is done in COBOL" 
and there is not an "other language that is a practical alternative for 
commercial work" - Call for feper, First European Conference on pragmatic 
programming & sensible software - 1978, J.Weinberg - With this letter we 
wish add ourselves to the chorus of other letters on the same matter that 
we have read on T&,scal Newsletters. 

Improvements ; 

^ " EJ^^merated scalar types; many commercial applications, and not only, 
use very much this kind of type, and their subranges, but variables 
of these types are incommunicable via standard Input/Output and exter 
nal files. In order to have a clear programming is quite useless their 
inner representation, it would be better their identifiers. 
A possibile solution is to use their names (with common reltrinctions) 
as strings in l/o, this is implementable if we do a pre-processor of 
the compiling sta^e that is not very heavy compared with the time and 
space used by other common compilers. 

2 - Strings ; we like the way of defining a string - packed array [l.-n] 
of char - but, in practical programming, strings must be of vaiying 
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lenght - with »n* as maximuiii lenght - With formatted input, it would 
iDe better to read the complete string in the same way as it is possi- 
hle to write it (also without format). I^ck and Unpack are useful pro 
cedures to process a character in a string "but they are not sufficient 
to use strings in programs, one must provide the complete set of opera- 
tors. 

We think that a good way of re-design this data type is to introduce 
string (n ) as base data type. 

3 - Formatted input ; we have read the proposed solutions of the quarrel 

in JFb,scal Newsletters, but is not a practical day-to-day solution. On 
the other without formatted input is difficult to use PASCAL in com - 
mercial applications because a blank in a (commercial) card is as im- 
portant as a character. 

4 - Case statement ; we enphasize the utility to have: 

case expression of 
value 1 ; 



value n: 
otherwise; 
in addition to actual <case statement^ 

5 - Interlanguage communication ; the "slogan" must be: "we have to manage 
the transition between old nad new systems". But more than this often 
it happens that one have to use existing packages (data-base, linear- 
programming) but not also, many times we have to interface a system 
that, for many reaso^s, must not be re-done. So it is very important, 
if we want to introduce the PASCAL Language, to have a construct to 
manage communication with FORTRAN", COBOL, Mj/1 . 

Epilogue 

We think it is very good to have a: 

"- sparse, simple language; 

- general purpose language; 

- vehicle for portable software; 

- tool for systematic programming; 

- etc. " 

but also that, if software workers do not use it, it means that we have not 
proposed a real alternative "to dinosaur languages" and to actual program- 
ming style. 

Sincerely 




J. E. POURNELLE AND ASSOCIATES 



12051 LAUREL TERRACE 



STUDIO CITY. CALIFORNIA 91604 



(213) 762-2256 



2 Feb 1978 

Dear Mr. Mickel, 

I have located a PRIMER of PASCAL and although I haven't 
obtained it yet — the bookstore is very slow — it promises to 
solve most of my bibliographic problems. 

In your package with the back issues of the newsletter you 
noted that you have a good PASCAL for a Z~80 system with disks. 

My system is a Cromemco Z-2 with 48 K RAM and 16 K ROM, iCom a 

disks with FDOS-3; CPM is also available. /\C^» Kav* Tlfi^/iML CUS^^Hf it^^t^, 

I would be very interested in obtaining a source code for PASCAL 
that I could get running. I do not expect to get this for nothing, 
and I am prepared to pay reasonable costs and fees; but I do 
need to know from whom I can obtain it. 

I enclose (1) a stamped self-addressed envelope for your 
convenience in replying, and (2) a check for $10 as a 
donation to the user's group, in the hopes that will 
provide an incentive for you to take a moment to reply. 

As the former President of a writer's association I know very 
well how volunteer and unpaid work eats up one's professional 
time and I recall from my grad student days just how little 
time is available; still, I do hope you'll be able to give me 
the information on how to acquire PASCAL. 

From all Ihear, including from friends out at JPL who work 
in programming the MARINER and PIONEER probes, PASCAL is 
very powerful and indeed probably better than some of the 
much- touted and much better known languages. I am about to 
write a whole mess of software and I would like to have the 
option of getting that done in PASCAL rather than FORTRAN or 
any of the 3 BASICS I have. 

"•fhank you again. 
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Open Forum for Members 
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Gentlemen: 



Box 11023 
Atlanta, GA 
30310 
USA 



Date : a'*" Feb 78 



To 



Pascal News 
University Computer 

Center 
University of 

Minnesota 
Mineeapolis, MN 

55455 



RE: Mr. R, A, Fraley's piece in the last Newsletter on 
suggested extensions . 

I miss dynamic arrays 5 being an Algols and I'd love to 
have real honest strings j too. 

However, I don't miss Common, and I don't think we need 
to have Modules, either. 

Common can be dismissed as a horror that allowed each 
subroutine in FORTRAN to cut up the shared data as it wished 
(thus Subroutine A was working on four integer, that Subroutine 
B thought were two Reals, etc.). It was as big a burden as a 
long parameter list, and it should die with FORTRAN. 

There is a nice feature in COBOL, PL/l and some other 
languages for COPY or INCLUDE verbs that allow the placement of 
text into the program from other files. 

Since this is an operrating system-compile time interface 
we could do the include at the source code level, the intermediate 
code level, or the binary code level. I favor the idea of doing 
it as source code, since optimizing work can be done better with 
constants being plugged in by actual user calls (there was a 
Student paper in CACM with some timing studies on this technique 
last year, that would be of interest), and since we must already 
have a good text file system. 

This would mean writ ting an extension to the compiler 
you now have that would recognize 

(include statement >:: = include (external file id) 

convert it into a comment, and append the proper file(s). 

A library would be defined as a procedure or function, 
a group of procedures or functions, or a group of procedures 
or functions preceded by a group of declarations. A crippled 
compiler could check to see that no executable statements were 
on file. By having the declarations in front of the procedures 
or functions we would get the shared variables via the existing 
Global conventions of Pascal, and it would cost us only a few 
extra lines in a compiler. Portability would not be affected. 
Optimizing would be possible (for example, deleting items that 
are not called by the program). 



Yours 
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Pascal User's Group 

c/o Andy Mickel 
UCC: 227 Exp. Engr. 
University of Minnesota 
Minneapolis, MN 55455 
(612) 376-7290 



Miinchen,den 23 . 02 . 1 97 8/HW-la 

Telefon (089) 21 05/84 84 

2105/ 
Telex: 05/24 634 
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Dear Andy, 

enclosed you find a list of wishes of an enthusiastic PASCAL- 

user. I have condensed it from discussions with some of my 

collegues who tried PASCAL for various problems. 

These wishes are not "filtered" by implementation considerations, 

but are propositions to make a very attractive language more 

usable. 

As I am preparing a PASCAL course for the users of our computing 
center, I would be very glad to receive a short note from you 
indicating the new features of release 3 of the compiler and 
the approximate date of distribution. 

Thank you in advance. 



oo 



Yours sincerely, 
(Hellmut Weber) 
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Direktorium: o. Prof. Dr. G. Seegmiiller (Vorsitzender), o. Prof. Dr. F. L. Bauer, o. Prof. Dr. G. Hammerlin, o. Prof. Dr. K. Samelson 



Joe Celko 



A PASCAL-user ' s viewpoint: 

1 . Extensions which I consider as necessary 

1.1 Dynamic array bounds, for example as describing by WIRTH 
and further explained by CONDICT in SIGPLAN letters. 

(It is ridiculous to have to write a separate inner- 
product procedure for every vector length. The devel- 
opment of procedure libraries would be drastically 
simplified.) 

1 . 2 Procedures which are parameters of other procedures must 
permit var-parameters 

(You don't have always one single value as result!) 

1.3 Formated i/o as an alternative for the existing READ 
and WRITE procedures. 

(It seems to be the only posibility on convince people 
who write production programs, and until now write them 
in FORTRAN or COBOL, whether you like it or not.) 

1 . 4 Structured Constants , 
especially constant arrays 

(Are needed if one wants to write library routines which 
are to be called very often by one program, e.g. Serees 
expansions) . 

2. Extensions which would make programming in PASCAL much more 
comfortable : 

2 . 1 Break__character 

2.2 All characters of a identifier should be significant. 

(The possibility of suggestive and self-dociimenting 
names is sever ly by the 8-char-rule. 
Regard 

Numberofpossibilities and 

Numberof realizations 
and compare it with 

Number__of__possibilities and 

Numbe r_o f __re a 1 i z at ion s 
Even the CDC character.. set has still unused characters.) 



2.4/More standard functions 
as y^, log^QX 

3. "Extensions" to be included in a sort of "standard" implement 
tat ion: 

3.1 Possibilities for interactive use! 

3.2 Extended file access: 

3.2.1 Possibility to append an element to a file after 
having read the file. 

3.2.2 Random access 

(KNUDSEN (ETH) described a sort of minimal version in PN.) 

4. Features every implementation should include: 

4.1. Simple possibility to generate library routines 

(e.g. Compiler-option which causes the compiler to 
assume the diimmy main program and to suppress the code 
generation for it. Non-standard type declarations needed 
for the library routine had to be placed after the "switching 
on" of this compiler option.) 

4.2 Possibility to compile several programs (or a program and 
separate libray routines ^ la 4.1) in one compiler run. 

4.3 Debugging aids: 

(there are no upper limits to the ingenuity of the 
compiler writer, but there should be at least a dump 
showing all variables, of structured variables I would 
accept the bit pattern. See for example the description 
of H.H. NAGEL in PN#4) . 

4.4 Compiler identification and statistics (Important for 
documentation and not much work fdr the implementor. ) 

5. Especially for CDC-users: 

Alternative characters for the important but dangerous 
characters ' : ' and ' A ' . 

Release 2 allows '%' instead of ' : ' (as proposed by VIM) 
but I didn't see the fact documented). 
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2.3 Alphanumeric labels 

(can indicate the condition of their use: 
error_in_input__data : ) 
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A COMMENTARY ON PASCAL NEWS No. 11 



A.H.J. Sale 
University of Tasmania. 



This report is a commentary on the contents of issue 11 of News; it may be of 
interest to PASCALlers in assessing where PASCAL is going and the value of the 
NEWS. 

Page 4 : David Barron's proposal for algorithms is excellent! Even if inter- 
program linkages aren't provided in a PASCAL version, source inclusion always 
is. I offer any help I can give regarding portability (alas, I am no numerical 
analyst) . Can I urge others to help too? 

Pages 8-15 : possibly news, abstracts, etc, are the most useful part of News 
that appears regularly. For me anyway. 

Pages 55-54 : a good summary of a serious 'compatibility' problem. For a long 
time I have liked SRTCCO (in the author's terms), but this is something a 
standard must resolve before I^ make a change. There are problems in SRTCCO in 
letting adjustable arrays in, aren't there? It would be interesting to know 
why the change to SRTCCl was made in later CDC compilers. 

Pages 54-40 : A contrast between a tale of woe and rosy future. It is good to 
see such a lot going on. Anyway, sometime soon it may be possible to present 
all these 'standard' compilers with a large suite of validation programs to 
exercise the claims a bit. It's being worked on in the UK by Brian Wichmann, 
and here by me. 

Pages 40-41 : Suggestions for compilers and my reactions: (1) I suppose ok, 
the comment idea is best, but you'd better look out if I find anyone allowing 
nested comments. (2) Yes; but possibly a good separate cross-referencer would 
do as well. (5) Must have this; we do. (4) I suppose so; it hadn't occured 
to me as a problem as I'd rather remove the packed symbols. (5) Not that we 
have it, but it is obvious that Kempton isn't a teacher of programming! Do 
whatever you want if you've got your own version about setting such defaults. 
They're nothing to do with PASCAL. (6) No comment needed. (7) God help us, 
why? Cannot input forms be identical to output forms and those in the language 
too? I regard things like 1. or .4 as quite abnormal; most scientists don't 
write them that way anyway. (8) What's wrong with Wirth's suggestion of writeln? 
(9) Some compilers do this now. (10) Possibly pre-defining more constants is 
a bit of a sledgehammer; a prologue to portable programs can invite users to 
change a const part ot suit their machine. 

Pages 41-48 : The set of Fraley extensions is too large to comment on. Most 
of them fall far, far beyond any current ideas of standardization of PASCAL 
which must include its warts as well as its beauty. I'll only comment on one 
semantic ambiguity at the end. (1) This is a violation of the principle of 
environmental independence of procedures; probably an oversight in PASCAL-P. 
The ICL and Tasmania B6700 do it properly; the compiler is marginally simpler! 
Pages 48-55 : What a welter of desire to change PASCAL! Can I re-iterate what 
Andy said: basic PASCAL is not up for grabs so that everyone can add their 
favourite feature . The Revised Report needs tidying up, yes, after all it was 
written for communication not as a standard. (Writing a standard calls for the 
same intellectual effort as proving programs correct.) But not wholesale 
revision. Only a very few 'agreed extensions' seem worthy of writing down; 
one that appeared in these pages was allowing of a wider class of type-changing 
procedures. This might be worth it if it stops people misusing variant records 
for the purpose (a very difficult thing to detect) . 

Pages 66-80 : Standards. It seems to me now that we could tidy up the loose 
ends if only all these efforts don't get in each other's way . It'd be a 
disaster if everyone started modifying compilers to fit into different views. 
I'm adopting the policy of still fixing bugs and things the current Report is 
quite clear on, but waiting a bit on any extensions until I see something all 
are agreed on. It is only a pity this effort is two years or so too late to 
forestall the variety. I'm delighted to see the bugs in PASCAL-P being brought 
out; I find I can detect the ancestry of compilers by the results they give to 
some test programs. And of course errors shouldn't be propagated. 



Pages 85-105 : Implementation notes: usually not comment -worthy. I feel I 
must say something about the lousy decisions people are making in the lexical 
area. Why on earth substitute # forO, or abbreviate procedure to proc? It 
is just pointless. Alternately, if the compiler is meant to be used in-house 
alone, why publicise it in News. Still, enough of gripes. I applaud the set- 
ting up of the ICL clearing house. PASCAL now has a canonic implementation 
for CDC Cybers, Decsystem 10s, UNIVAC 110s, and ICL gear. The IBM and PDP-11 
situations are the most worrying, though I think the rumors I get suggest that 
the AAEC version (see p94) of IBM is quite good (if you keep away from the 
extensions) . 

Overview : If this sounded critical in places, please take in it context. I 
think News is growing up, and the standard of news and contribution is getting 
much better. I'm glad we are going to have an 'Algorithms Section', and I 
hope we'll have critical contributions on what's published there. A lot of 
the portable software I send off for isn't, and requires work to repair the 
defects which should have been done by the designer. On extensions, I'd really 
suggest that everyone stop writing them into News since we have too much already. 
Checklists of troublespots would be welcome, but no new ideas please. For my 
piece of mind alone, if not Andy's. 

Thanks 
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It is now two years since Andy took up the task of News editor, and just so he 
doesn't despair and think the task thankless, I'd like to express all Pascallers 
thanks to you Andy, for the tremendous job you've done. I don't know how you 
find the time, really I don't. Anyway, thanks. 



THE UNIVERSITYOF KANSAS/LAWRENCE, KANSAS 66045 



Department of Computer Science 
18 Strong Hall 
913 864-4482 




27 February 1978 



to 
oo 



Pascal User's Group 

c/o Andy Mickel 

University Computer Center: 227 EX 

208 SE Union Street 

University of Minnesota 

Minneapolis, MN 55455 



Dear Andy, 



Shame on you! I expect that the only reason you included R. A. Fraley' s 
papers on "Suggested Extensions to Pascal," in PN #11, was to scare the 
living begabbers out of us. Congratulations. You were terrifyingly 
successful. By the end of the second paper I was quaking in my chair 
(actually, I was expecting to see such things as proposals for long and 
short int, packed decimal, on condition constructs, sort, and all of the 
rest of Fortran (ugh!), COBOL (ugh! ugh!), and PL/ I (ugh! ugh! ugh!) to 
be included. Tighten your belt and stand by your guns, I'm sure there's 
more to come. 

Sincerely, 



CD 



Gregory F. Wetzel 
Research Assistant 




eric small & associates, inc. 

consultants in broadcast tecl^nology 

680 beacfi street suite 365, son francisco, California 94i09 telephone (415) 441-0666 



March 6, 1978 

Pascal User's Group 

C/0 Andy Mickel 

University Computer Center: 

22 7EX 

208 SE Union St. 

Univ. o£ Minn. 

Minn, MN. 55455 



Dear Andy, 

We are looking for a PASCAL programer to join our merry band. 

The ideal candidate will be a recent graduate. He or she will 
have had a lot of PASCAL experience. Exposure to broadcasting 
operations or engineering would be very desirable, possibly col- 
lege radio. 

Seven people comprise ESA. Dave Rowland, one of the implementors 
of ESA pascal, is our lead software engineer. We are developing 
a line of LSI- 11 based products for the radio and TV braodcast 
market. 

Sincerely, 



Small 
President 



TO: Andy Mickel 
Editor, 
PASCAL NEWS 



March 



1978 



I would like to address certain misconceptions which may have been 
generated by Professor Arthur Sale's letter in PN#11 (page 75), titled 
"Unimplementable Features — Warning". 

Professor Sale expressed concern about extensions which some PASCAL 
implementors have added to their implementations. He claims that these 
extensions are "not implementable on the Burroughs B5700 system and 
possibly on other computers." Not only is this claim false in the 
general case (we are, after all, dealing with computers as powerful as a 
Turing machine), but there exist relatively simple implementations of 
two of the three extensions which he uses as examples. 



(1) "Passing pointer values as addresses, even in-stack" 

Professor Sale's observations in this case are correct, if over 

stated. It would be inconvenient to implement pointers to non-heap 

variables on a B6700 system while realizing the advantages of its 
architecture. 

However, there is a more important reason why this extension is not 
advisable -- the "up-level pointer problem" (and the related "dangling 
reference problem"). This reason alone, apart from any implementation 
difficulties, is sufficient to reject such an extension to PASCAL. 

(2) "Returning function values of all kinds except files" 

Professor Sale has misstated the facts about the 36700 RETN 
operator. He claims that only operand values (with zero tag) can be 
returned without causing an "Invalid Operand" interrupt. In fact, 
however, the S5709 will allow a word with any tag to be returned from a 
function via the RETN operator. In particular, a data descriptor can be 
returned quite easily by this method. However, there are other reasons 
(notably, software conventions) why this approach is not a wise 
implementation choice. 

There is, however, a very clean and simple way of implementing a 
function return of a descriptor-based type. The most recent release of 
the B6700 Extended ALGOL compiler (version III.O) includes the new data 
type "STRING". Values of type STRING can be returned from a typed 
procedure. The implementation technique for this descriptor-based type 
may easily be adapted to arrays or records. The B6700 PL/I compiler has 
used a similar technique for several years, although the new ALGOL 
STRING implementation is somewhat simpler. 

Besides the availability of a suitable implementation, returning 
such data values from functions seems to be a reasonable language 
feature. After all, records and arrays may be assigned values and may 
be passed as parameters by value. There is no fundamental difference 
between these uses of data values and their use as the returned type of 
a function. 

(3) "Allowing pointers to file-types and the use of new(file)" 

While I have argued on grounds independent of implementation that 
pointers should not be allowed to reference non-heap variables and that 
records and arrays should be allowed to be returned from a function, I 
will not take sides on the issue of files in the heap. I will only 
point out that the restriction that file descriptors must reside in the 
program stack is a software convention, not a hardware restriction. 
Furthermore, if the heap is marked as a "dope vector", no more than a 
few lines of changes to the operating system are required to make files 
whose descriptor resides in the heap behave normally with respect to 
being properly closed and deallocated at end-of-task. 
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THE UNIVERSITY OF NEBRASKA 
COMPUTER NETWORK 



March 10, 1978 



Dear Mr. Mickel: 



I maintain PASCAL at the University of Nebraska in 
Lincoln, and have decided I need my very own personal copy 
of PASCAL NEWS, so I am enclosing a check for membership 
for 1977-78. 

Looking at the different mutually incompatible versions 
of PASCAL serves to emphasize one point strongly- -that PASCAL 
needs standardized extensibility. To each his own (idiosyn- 
cracies , environments, needs, etc.). If extension mechanisms 
are developed for PASCAL, as they have for ALGOL 68, a 
standard PASCAL implementation could be defined as one whose 
correct programs ran correctly (even if inefficiently ) on 
another standard PASCAL when enclosed by a prelude or environ- 
ment extension/redefinition block and called as a procedure. 
Such mechanisms should also enable character set redefinition, 
reserved word redefinition, etc. 



Ideas anyone? 




Bhaskar 
Acadp-rfic Computing Services 



cadp-rfi 



Oslo, Marcli 15, 1978 



Dear Andy, 



I am presently working on a new implementation of Pascal 
for the Nord-10. The implementation is based on the TRUNG 
compiler. I would like to communicate with others who 
have done or plan to do likewise. 

Somehow I must interface the compiler to the environment 
in which it is to be used. This means that I have to invent 
a set of "features'* to go with the implementation - features 
which already have been invented a lot of times by others. 

Trying to turn some of the stones in this field started a 
train of thoughts, some of which are refelcted in the enclosed 
article. My hope is that the article will provoke a discussion 
about how the field ought to be plowed. 



Yours sincerel: 



Terjfe Hoodt 
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Tektronix, Inc. 
P.O. Box 500 
Beaverton, Oregon 97077 
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Phone: (503) 644-0161 
TWX: 910-467-8708 
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March 16, 1978 



Pascal News 

Andy Mickel 

University Computer Center: 227Ex 

208 S. E. Union Street 

University of Minnesota 

Minneapolis, MN 55455 

Dear Mr. Mickel: 

Interest in Pascal has been growing among software engineers at Tektronix 
for some time. Within Tektronix, wide use is made of many dialects of 
Pascal for various programming purposes. However, Tektronix does not 
currently have any products incorporating Pascal programming capabilities. 
Tektronix will not offer such products unless and until we can do so 
within our requirements for utility and quality. 

Because of the many (somewhat incompatible) dialects of Pascal currently 
in use and the possibility of Pascal *s application to some future products, 
Tektronix has recently engaged in a study of Pascal extensions. The 
results of that study are not yet available, but will be made available 
to the summer workshop proposed by Ken Bowles in Pascal News #11. We 
expect to offer these results for publication in Pascal News #13. 

Sincerely, 

TEKTRONIX, INC. 



GO 



Dr. Don Terwilliger 
Manager, Computer Research 
Tektronix Laboratories 
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Mr. Andy Mi eke 1 

Editor, Pascal News 

University of Minnesota 

University Computing Center 

227 Experimental Engineering Building 

Minneapolis, Minnesota 55455 

Dear Andy, 

It is such a temptation to detail all my opinions, just because 
they are mine, even though others have already said the same. 
Luckily I am pressed for time and the resistance is relatively 
easy; I think each of the following is in some way new. 

1. I enjoy reading Arthur Sale's prolific comments - he is one 
who often states my opinions. I do object to one aspect of his 
contributions: his consistent referral to the University of Tas- 
mania's Pascal compiler as "The B6 700 compiler". I use a dif- 
ferent Pascal compiler on the B6 700 (produced by Kenneth Bowles' 
group at UCSD) , know of still another, and hear rumors of one 

or two others. I expect the Tasmania compiler is a very good 
one, but it is not the only one. 

2. I agree with Arthur Sale's conclusions that certain non- 
standard features should be avoided. I do not agree with his 
reasons. These features are not unimplementable on the B6700, 
as he claims, or the difficulties as horrible as he puts forth. 
The proper reasons for not implementing these features deal 
with the language itself, not with a particular implementation. 
The difficulties encountered on the B6 700 are most valuable 
when used to give insight on future machine design. 

3. Formal procedures and functions should be completely speci- 
fied; the lack thereof is merely a bad holdover from ALGOL60. 

(I suspect the lack of specification is one reason so many com- 
piler writers omit this feature.) Declaration of procedure 
types as suggested by George Richmond (PN#8 p 13) leads to such 
questions as 

Are procedure variables allowed? 

Should procedures be declared in the VAR section? 

Why does a procedure have an initial value (the body) when 

other variables not? 
ad nauseum. These problems should be left to ALGOL68. There- 
fore the specification should be in-line only. To do so, change 
the definition of <formal parameter section> to read 



Mr. Andy Mickel 
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: : = ^parameter group> | 

var <parameter group> \ 

<procedure heading> | 

<function heading> 

This generates an extra semicolon, so the definitions of pro- 
cedure and function declaration and heading must be altered to 
take this into account. This affects pp 112,155 and 159 of 
the PUM&R; also affected is the program on p 79. Restriction 
2 on p 83 can then be dropped. This usage assumes that the type 
compatibility checking is, in the terminology of Desjardins 
(PN #11 p 33) , SrtCCI; otherwise no two procedures would ever 
be compatible as types. 

4. Standard methods for data transformation are needed, particu- 
larly for conversion between character and integer or real; 
these methods may be functions or procedures or statements. 

This issue has been much discussed under the guise of formatted 
I/O. I believe that embedding the transformation of activity 
into "formatted I/O" unnecessarily complicates the I/O part 
of the language and unnecessarily restricts the conversion features. 

I cannot let Barron & Mullins' argument (PN # p 8) pass unnoticed. 
Packed data i£ necessary at times, though formatted I/O is not. 
My agency handles about 10000 title activity transactions per 
day, with about 30 fields each. 

10000 transactions/day x 30 separators/transactions 
= 30000 keystrokes/day 

- 30 key entry stations Sopera tors 

= $30,000/month 

$360,000/year to use separators. 

5. There have been many proposals for extending Pascal's I/O, 
but usually with no mention of the overall I/O facility which 
results. Pascal I/O needs improvement, but suggestions should 
be limited to proposals for a simple, consistent and complete 
I/O facility, never for isolated features. 

Sincerely, 
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Pascal User's Group, c/o Andy Mickel 
University Computer Center: 227 EX 
208 SE Union Street 
University of Minnesota 
Minneapolis, MN 55455 USA 
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Andy Mickel 
Editor, Pascal News 

Dear Andy: 

Enclosed is ray membership form for PUG. You're doing a great 
job. Keep up the good work! 

PASCAL is indeed catching on within Computer Science depart- 
ments, but, despite the numerous examples mentioned in PN, most 
other groups I have seen are reluctant to use PASCAL in place of 
more available and familiar tools. In particular, PASCAL will 
never replace BASIC or FORTRAN as long as these languages provide 
features that are sorely lacking in PASCAL. In particular: 
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Dear Andy, 



thanks for Pascal News 9 and 10. We finally have completed our 
work on a version of our portable Pascal-System (cross-ver- 
sion). The first implementation is now on an MDS800 (Intel 8080 
microprocessor), using the ISIS II operating system. 

Just some short notes about the history of the project. We deci- 
ded to implement a portable programming system for the different 
computers in the Siemens product-field, i.e. 32bit, l6bit and 
8bit machines. We came upon Pascal after an implementation of 
a self- invented language, whose syntax and parts of its data- 
concept were mainly influenced by Pascal. This language was 
but experimental and could not be used as base for a programming 
system. 

Our main goals were portability of user-programs as well as 
portability of the system itself. We think we now have reached 
both, the first by implementing Standard-Pascal and no dialect 
at all, the second by using just high-level languages for imple- 
mentation (mostly Pascal, of course). 

Our plans for the near future are a resident version and system- 
dependent features as a code-generator, generating some form 
of threaded code. Also a machine-independent dialogue-system 
has to be developed. 

Please do note our new address. 



Sincerely 




Werner Remmele 



Adfesse : 

Siemens AG, Zentralbereich Technii< 

Zentrale Forschung und Entwicklung 

Forschungslaboralorien 



Postfach 832729, D-8000 Munchen 8: 



6782- 4622 

Vermittlung 6782-1 



El 

528384 



SIEMENS AKTIENGESELLSCHAFT d f n va/ u w 

Zentrale Forschung und Entwicklung • Forschungslaboratonen Leitung: Prof. Dr. Walter Heywang 



Vorsitzender des Aufsichtsrats : Peter v. Siemens • Vorstand: Bernhard Piettner, Vorsitzonder • Mitgiieder: Theodor Baumann, Fn 
Heinz Gumin, Ulricln Haler, Giseiiier Kadegge, Karlfieinz Kaske, Friedrich Kuhrt, Walter Mohr,W9rner Mulder, Herioa.d Narge^ H,.oc.( 
Wolfgang Seelig, Hans Gunter Vogelsang, Helmut Wilhelms 



I der Gesellschaft; Berlin und Miinohen • 



-jfch Eaur, Hans Baur, Helmut Becker, Paul Dax, Max Guntiier, 
erd Mealed Doacnim v. Oertzen, Anton Peisl, Dieter v. Sanden, 
: Berlin-Charlottenburg, 93 HRB 670; Munchen, HRB 6684 



FORTRAN has static variables, external compilations, ini- 
tialization of variables (in particular, arrays), procedures with 
flexible sized array parameters, STOP and RETURN statements, for- 
matted input with error detection under user control, and large 
libraries of applications packages. PASCAL does not. In particu- 
lar, complex numbers would not be missed if a standard subroutine 
package were available. 

BASIC is, despite its lack of power, an extremely friendly 
language to beginners. Most idiosyncracies are hidden from the 
user - only one numeric data type, arbitrary length character 
strings, general FOR loop. Interactive programs are natural. The 
notion of "One line = one statement" is much easier on the be- 
ginner than PASCAL'S relatively complicated set of syntax rules. 
BASIC'S editor is very easy to learn. 

I have many gripes about PASCAL - mostly concerning features 
that have been left off. Despite it's goal of being systematic, 
PASCAL has formatted output (but no formatted input.) It can read 
and write integers, reals, and characters, (but not enumerated 
types or records, and to add to the confusion, you can write 
booleans and packed arrays of characters but not read them! ) 
PASCAL has constants of type integer, real, boolean, character, 
and set, (but no const declarations of type set, and no record or 
array constants or constructors.) Functions can return integers, 
reals, characters, booleans, pointers, enumerated types, and 
subranges (but not records, sets, or arrays.) There are numerous 
places where a type identifier is allowed but a type may not be 
constructed. Semicolons come after most statements (but not be- 
fore end and never before else . ) I also feel strongly that stop , 
return , exit, and next statements are necessary to promote struc- 
tured programming. 
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Walt Brainerd proposed a loop construction for FORTRAN that 
solves the "exit in middle of loop" problem (SIGPLAN Dec. 77). 
Such a constructon can be PASCAL-ized and modified to reflect my 
own biases as is shown in the first syntax diagram. The seman- 
tics are that loop ... end cause repetition, and the various oth- 
er parts give ways to get out of the loop. The for part has the 
same meaning as PASCAL'S for statement: vary the index from the 
initial value until the final value and then quit. The while 
part also has the usual semantics: 

if not <expression> then exit 
The flag part lists one or more identifiers which should be de- 
clared as boolean variables. Entering the loop sets all the vari- 
ables to false. An. exit statement naming a variable sets that 
variable to true and jumps out of the loop. It is possible to 
jump out of more than one level of loop by naming a variable in 
the outer loop's flag part. If no variable is named, none is set, 
and the innermost loop is exited. The next statement behaves just 
like the exit except that rather than jumping out of the loop, 
the remainder of the loop body is skipped and the next execution 
of the loop begins (after any appropriate incrementing and test- 
ing of for and while parts,) and the boolean named is not set to 
true. (The only purpose of a variable in a next statement is to 
specify more than one level of loop.) If all three parts are left 
out of the loop header, an infinite loop results (presumably con- 
taining an exit statement somewhere.) Assigning true to one of 
the flag variables has no effect, is bad style, and might be 
prohibited. 

This construction has a number of advantages. It includes 
the power of PASCAL'S for , while , and repeat statements into one 
construct. It also has the power of being able to exit or resume 
one or more levels of loops from any point in the middle. In 
addition, when you get out of a loop, you can test the boolean 
variables to see what caused loop termination. Consider for 
example binary search: 

1 := 1; u := n; 

loop while (1 <= u) flag found do 
mid := (1+u) div 2; 
if X < A[mid] 

then u := mid-1 
else ij^ X > A[mid] 

then 1 := mid+1 
else exit found 
end; 

if found then writeln( ' Found at', mid) 
else writeln( 'Not found'); 

Another example, finding prime numbers: 

loop for p : = 2 to n flag potential prime do 
loop for d := 2 to trunc(sqrt (pT) do 



end; 



if p mod d 
end ; 
write(p) 



^ then next potential prime 



The second example above seems to be one case where PASCAL 

really needs a step option in the for loop, since it is only 

necessary to check the odd numbers and divisors. What is so all 

fired important that makes increments other than 1 and -1 against 
the spirit of PASCAL? 

This construction is powerful enough to replace for , whil e , 
and repea t loops. A lone for or while part on the loop statement 
gives you the for and whi le loops, and a while part on the loop 
end gives you the repea t ... unti l construction. 

In principle, the while clause is unnecessary, since a con- 
ditional exit at the beginning or end of the body will have the 
same effect. I argue that the while construction provides addi- 
tional readability. The keyword flag is perhaps not ideal, 
Brainerd used until , which would only cause confusion in PASCAL. 
Another keyword, such as conditions , could be substituted. 
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implementation of a PASCAL based Artificial 
called TELOS. This language is a superset 
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A TELOS implementation is currently under development based 
on Charlie Fischer's UNIVAC 1100 PASCAL compiler, which currently 
has most of the data base features implemented. Work is also 
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beginning on a portable TELOS interpreter based on the P Com- 
piler . 
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Syntax Diagram 1 
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loop statement 

loop header 1-^ ^ statement | -^ — > | loop trailer [ ^ 



Mark Horton 

Computer Sciences Department 

University of Wisconsin, Madison 

1210 W Dayton St. 

Madison, Wisconsin 53706 



loop header 

^/loop 

loop trailer 



i-p-^for partj^ |- ^while paTt[ -^ — | ^flag parTL , ^(do) ^ 



»(^^END)-y-» | while part \ -iff 

for part ' 

J(j^OR) ^variable identifier} j^j^V ^xpression^ 



-^ I — \ expressio 

-o^J 




iable identifier] — i— » 

-^ 1 



simple statement 




EXIX ) r— ^variable identifier} -^ => 



— > (neXT ) p- ^variable identif ier|- ;r -, 



Syntax Diagram 2 



statement 



HILE )— 4"ex press ion} — A flag part ^ tk— ^(po) » } statement} — ^- 

^flag part |7|p]rj{ s tat ement}—|-4(tlNTIL)—>| expressio 



O 




'^^'^^03)— H variable identifier } —»(;=)-> jexpressi 

L-»|expression}-p-» |"flag part[ -y-^(1^0^- ^ statement]— ^ 

^XIT )-r 4 vai^^ab^e identif ierT -y» 

I » (NEXT )-r- ^ variable identifier f -y-^ 



flag part 

— ^FLAG ^ variable identifier 

G> 



tr 




Westinghouse 
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Defense and Electronics Systems Center 
Systems Development Division 

Baltimore-Washington Lnternationai Airport 
Box 746 mJ. 451 
Baltimore Maryland 21203 



April 11, 1978 



Mr. Andy Mickel 
Pascal User's Group 
University Computer Center 22TEX 
208 SE Union Street 
University of Minnesota 
Minneapolis, MN 55^55 

Dear Mr. Mickel: 

I have been aware of PASCAL for several years. Recent interest "by 
Department of Defense in PASCAL as a base for a DoD's Common Programming 
Language Effort has stimulated my interest. I am deeply involved in the 
DoD vorld of software and its unique problems. Possibly PUG can help with 
one unique problem, ie . The government requires detailed specifications 
for everything, including software. Further, the government requires accep- 
tance test to be sure specifications are met. Is it possible for PUG to 
develop an acceptance test for PASCAL compilers? Don't answer too quickly. 
An acceptance test, that might satisfy government standards, requires the 
following: 

1) a detailed, unambiguous specification. 

2) A test against every item in the specifications. 

As a case in point, Rome Air Development Center has a JOVIAL J73/1 
compiler validation (acceptance tests) against MIL-STD-I589, that has over 
20,000 source JOVIAL statements in 28 source modules. The JOVIAL validation 
is compiled and executed. The results of the execution are several thousand 
"TEST PASSED" or "TEST FAILED" messages with appropriate comments about the 
language feature being tested. 

My group will soon be getting a PASCAL compiler for the UNIVAC 1110. 
Since the compiler may be used on government contracts, it would be a great 
help if an acceptance test was available. 




/Jon S. Squire, Manager 
Operational Software 

JSS:j 
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University of the Witwatersrand, Johannesburg 

DEPARTMENT OF APPLIED MATHEMATICS 

1 Jan Smuts Avenue, Johannesburg, 2001, South Africa 
Telephone 39-4011, Telegrams 'University', Telex 8-7330 SA 




The Editor, 
Pascal News. 



telephone ext 
your reference 
our reference JB/SW 

date 7 April 19 7 £ 



Dear John, 

Thanks for your note - the question of predefined types also 
requiring a succ(max) facility had not occurred to me when I 
wrote "Subranges and Conditional Loops". The convention I 
suggest only works for genuine subranges, not full ranges such 
as integer, char and boolean. I thought long and hard of the 
possibility of letting these types be subranges of underlying 
and hidden ranges. These ranges would be one bigger on either 
side than the subrange we see but these "fringe" elements would 
not be accessible. Diagrammatically, we want 



CHAR 



accessible to 
programmer 



E 



CHAR 



accessible to 
system 



The idea would be to let a program declare 

var ch : 0. . succharmax 
and write 

ch: = charmin; 
while (ch <* charmax) and condition do 
begin 

(* something *) 
end; ^^^ •= s^^^ ^^h) 

The trouble is that the fringe elements are accessible: if succ(ch), 
when ch=charmax, is a valid expression then there is no way of 
stopping a program from writing it out - which would be invalid. 
Furthermore, there may be severe implementation problems since 
these types have a "fully packed" property i.e. they are usually 
represented in the exact number of bits required for max. 

This leads me to realize that the predefined types, namely char, 
boolean and integer, are ranges and have a different nature to 
the subranges that we build on top of them. For the first time I 
feel some sympathy with Haberman and his "Critical Comments"! 
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To obtain the full effect of the above program in standard Pascal 
requires a boolean i.e. 

var ch : char; 

ch := charmin; 

indexended := false; 

while not indexended and condition do 



begin 



(* something *) 
if ch = charmax then indexended : = true 
else ch := succ (ch) 



This use of booleans is similar to that required to simulate 
sequential conjunction. I must admit that I don't like it and 
wonder if one day we'll have a "Booleans Considered Harmful" 
article. 

I would be very pleased to hear if other Pascal people have 
thought about this problem and have alternative views to mine. 

Enclosed are some membership forms - dollars are coming separate- 
ly by Postal Money Order. 

Best wishes. 




JUDY BISHOP 



End. 
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(* Note: This letter is in reply to a letter sent on 78/03/08 from John Strait 
to Judy: 

"Belated congratulations to you and Nigel! We received your 
card — you two make a handsome couple. 

Andy let me read your article "Subranges and Conditional Loops" 
which he received yesterday. I have a question: What do you 
do with a pre-defined type which cannot be redeclared (e.g. CHAR) 
or one with special meanings (e.g. BOOLEAN). I ran into this 
problem last week with CHAR. Aside from this problem, I found 
your solution interesting/elegant." 

*) 
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Pascal STANDARDS 

PLEASE DIRECT ALL INQUIRIES, LETTERS, 
ETC. ABOUT Pascal Standards to 
Tony. Thanks, Andy. 



PASCAL syntax 



NW 12.3.78 



Editor: Tony Addyman Department of Computer Science 
The University 
Manchester M13 9PL 
United Kingdom 

(phone: 44-61-273-7121 x5546) 



Jim Miner and I would like to bring you up to date on recent standards developments. 
First, Ken Bowles at the University of California, San Diego, has failed to keep us 
informed about his proposed summer workshop. We have no news since last issue! 

Beginning this January, J^rgen Steensgaard-Madsen of the Datalogisk Institut, 
University of Copenhagen, Denmark, has done all Pascal ers a favor by initiating work on 
the difficult task of conventionalizing extensions— thus answering Pierre Desjardins's 
good question in the last issue of PUGN. JjiJrgen is working in cooperation with Niklaus 
Wirth and several implementors: Jeff Tobias and Gordon Cox (IBM 370) in Australia, 
H. H. Nagel (DEC 10), in Germany, Olivier Lecarme (CII IRIS) in France, John Strait 
(CDC 6000) in the USA, Arthur Sale (B6700) in Australia, Ken Bowles (DEC PDP-11 and 
micros) in the USA, and Jim Welsh (ICL 1900) in the UK. 

Olivier Lecarme published letters from Niklaus Wirth in the Bulletin No. 3 for the 
French Working Group on Pascal in March. The hope was expressed that this is hopefully 
the final work done in this area and that progress could be made if the number of people 
were kept small and the range of topics to be considered kept limited. 

J0rgen is in contact with Tony Addyman who continues making progress on an ISO standard 
with his 10- (so far we at PUGN don't know who they all are) -person BSI working group 
called DPS/13/4. Tony now expects to have a draft document by the end of September. 

In the course of our correspondence with J0rgen and Niklaus, we discovered another 
standardization effort begun by Justin S. Walker at the National Bureau of Standards (NBS) 
within the U.S. Government. He coincidental ly (?) joined PUG 2 weeks later. We sent a 
personal letter to him trying to determine just what he is doing, and he did not answer. 
Hmmmmm . 

Below is news from Tony and DPS/ 13/4: an Attention List #2. 

Following that are several letters. Charles Fischer of the University of Wisconsin 
and Richard LeBlanc of Georgia Institute of Technology have stated very clearly some 
widely-held concerns over standards. Jim and I wholeheartedly agree with them. 

Bob Vavra has written an outstanding and timely article and letter on design goals. 

Arthur Sale has issued a revised version of his "Pascal Compatibility Report" 
[Department of Information Science Report No R78-3, May, 1978] which we described last 
time in this space. It now includes many more implementations. 

Arthur is working with Brian Wichmann, of the National Physical Laboratory, in the 
United Kingdom on a set of Pascal programs to do: 1) Validity Checks - Does the compiler 
accept standard code, normal, or wierd? 2) Quality Checks: How does the compiler cope 
with error and error recovery? and 3) Compatibility Checks: How does the compiler cope 
in the undefined areas? 

- Andy and Jim 



April 7, 1978 



Dear Andy, 



I enclose a Pascal syntax written in EBNF. Would it be of 
any interest to the Newsletter? 



ETH 



EIDGENOSSISCHF TECHNISCHE HOCHSCHULE 
ZORICH 



Institut fijr Informatik 



Best regards. 

Prof. Niklaus Wirth 



(Extended BNF: cf. Comm.ACM 20, 11, p. 822, Nov. 1977) 



["E" ScaleFactor] . 



I SetType I FileType) . 
" ] " OF type . 



•;" variant}. rn 



identifier = letter {letter I digit}. 

IdentList = identifier {"," identifier}. 

Unsignedlnteger = digit {digit}. 

UnsignedReal = Unsignedlnteger ["." digit {digit}] 

sign = "+" I "-". 

ScaleFactor = [sign] Unsignedlnteger. 

UnsignedNumber = Unsignedlnteger I UnsignedReal. 

String = " '" character {character} "'". 

ConstantDef inition = identifier "=" constant. 

Constantldentif ier = identifier. 

constant = [siqn] (UnsignedNumber I Constantldentif ier) I string. 

TypeDef inition = identifier "=" type. 

type = SimpleType I StructuredType I PointerType. 

SiinpleType'= Typeldentif ier I ScalarType I SubrangeType. 

Typeldentif ier = identifier. 

ScalarType = "(" IdentList ")". 

SubrangeType = constant ".." constant. 

StructuredType = [PACKED] (ArrayType I RecordType 

ArrayType = ARRAY "[" SimpleType {"," SimpleType} 

RecordType = RECORD FieldList END. 

FieldList = [FixedPart] [Var iantPart] . 

FixedPart = RecordSection {";" RecordSection} . 

RecordSection = [IdentList ":" type]. 

VariantPart = CASE [identifier ":"] Typeldentif ier OF variant 

variant = [CaseLabelList ":" "(" FieldList '»)" ]. 

CaseLabelList = constant {"," constant}. 

SetType = SET OF SimpleType. 

FileType = FILE OF type. 

PointerType = "''" Typeldentif ier . 

VariableDeclaration = IdentList ":" type. 

variable = identifier {index | "." identifier I "T"}. 

index = "[" expression {"," expression} "]". 

expression = SimpleExpression [relation SimpleExpression] . 

relation = "=" I "<>" I "<" I "<=" I ">" I ">=" I IN. 

SimpleExpression = ["+" I "-"] term {AddOperator term}. 

AddOperator = "+" I "-" I OR. 

term = factor {MulOperator factor}. 

MulOperator = "*" I "/" I DIV I MOD I AND. 

factor = variable I UnsignedConstant | FunctionDesignator I set I 

"(" expression ")" I NOT factor, 
set = "[" [element {"," element}] "]". 
element = expression [".." expression]. 
FunctionDesignator = identifier [ActualParameterList] . 
UnsignedConstant = UnsignedNum.ber I string I Constantldentif ier I NIL. 

statement = [label ":"] UnlabelledStatement . 

UnlabelledStatement = SimpleStatement I StructuredStatement. 

SimpleStatement = [AssignmentStatement I ProcedureStatement I GotoStatement] . 

AssignmentStatement = variable ":=" expression. 

ProcedureStatement = identifier [ActualParameterList] . 

ActualParameterList = "(" expression {"," expression} ")". 

GotoStatement = GOTO label. 

label = Unsignedlnteger. 
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StructuredStatement = Compoundstatement | ConditionalStatement I 

RepetitiveStatement I WithStatement. 
Compoundstatement = BEGIN statement {";" statement} END. 
ConditionalStatement = IfStatement I CaseStatement . 
IfStatement = IF expression THEN statement [ELSE statement]. 
CaseStatement = CASE expression OF case {";" case} END. 
case = [CaseLabelList ":" statement]. 

RepetitiveStatement = WhileStatement I RepeatStatement I ForStatement . 
WhileStatement = WHILE expression DO statement. 

RepeatStatement = REPEAT statement {";" statement} UNTIL expression. 
ForStatement = FOR identifier ":=" ForList DO statement. 
ForList = expression (TO I DOWNTO) expression. 
WithStatement = WITH variable {"," variable} DO statement. 

ProcedureDeclaration = ProcedureHeading block. 

ProcedureHeading = PROCEDURE identifier [FormalParameterList] ";". 

FunctionDeclaration = FunctionHeading block. 

FunctionHeading = FUNCTION identifier [FormalParameterList] ":" 

Typeldentif ier " ; " . 
FormalParameterList = "(" FormalParameterSection 

{";" FormalParameterSection} ")". 
FormalParameterSection = [VAR | FUNCTION] IdentList ":" Typeldentif ier | 

PROCEDURE IdentList. 

block = [LabelDeclarationPart] [ConstantDef initionPart] [TypeDef initionPar 
[VariableDeclarationPart] ProcedureAndFunctionDeclarationPart 
StatementPart. 

LabelDeclarationPart = LABEL label {"," label} ";". 

ConstantDef initionPart = CONST ConstantDef inition ";" {ConstantDef inition 

TypeDef initionPart = TYPE TypeDef inition ";" {TypeDef inition ";"}. 

VariableDeclarationPart = VAR VariableDeclaration ";" {VariableDeclaration 

ProcedureAndFunctionDeclarationPart = 

{ProcedureDeclaration ";" | FunctionDeclaration 

StatementPart = Compoundstatement. 

program = ProgramHeading block "." . 

ProgramHeading = PROGRAM identifier "{" IdentList ")" ";". 
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Keywords 



AND ARRAY BEGIN CASE CONST DIV DO DOWNTO ELSE END 
FILE FOR FUNCTION GOTO IF IN LABEL MOD NIL NOT 
OF OR PACKED PROCEDURE PROGRAM RECORD REPEAT 
SET THEN TO TYPE UNTIL VAR WHILE WITH 
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061-273-7121 X5546 
6 February 1978 



Dear Andy 

This letter will serve several purposes. These are: 

1. To tell you my new phone number for the roster. 

2. To give and all others at PUG central the latest Attention 
List. As I said in my call, don't be alarmed by some of the 
items I still operating on the same basis as before. 

3. I wpnt to include several paragraphs from the beginning of 
Pascal News as an appendix to the textbook. This will serve 
to advertisf^ FUG by describing Pascal News, giving the 
central and regional addresses etc.. If space permits I 
would like to include a copy of the All-Purpose-Coupon, 
ivill this be OK? This does not need a reply. I .will call 
you. If you cannot be around, you can always leave a 
simple yes/no answer. 

4. A reminder to all PUG members that any contributions to 
the standardisation effort xatIii be gratefully received by 
myself and other memoers of DPS/13/4. 

5. As the enclosed material is rather bulky, you may print it 
or not as you see fit. Hopefully I will be able to send 
you some m.ore up-to-date information before the next issue 
is due to by printed. 
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Predeclared identifiers 



ABS ARCTAN BOOLEAN CHAR CHR COS DISPOSE EOF EOLN 
EXP GET INPUT INTEGER LN NEW ODD ORD OUTPUT PRED 
PUT READ READLN REAL RESET REWRITE ROUND SIN SQR 
SQRT SUCC TEXT TRUNC WRITE WRITELN 



Yours 
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Telephone: 061-273 5466 



1st February 1978 

TO: Members of DPS/IS/A, the Swedish Technical CoiteftXt tee on Pascal and all 
Correspond ants . 

May I first apologise for the delay in the production of Attention List 
ff2, I (wrongly) decided to keep altering tlie list to include new material. 
Had I realised that it would take such a long time to produce the list, I would 
have issued an incomplete list earlier. 

It is my hope that the list contains all the doubts and problems concerning 
Pascal which have been brought to my attention. If this is not so, then the list 
will be updated. 

Since it is a long time since DPS/13/4 last held a meeting, and several 
of its members are very active, I am suggesting that a meeting be held in late 
February or early March. The meeting cannot be called too soon because the 
Swedish Technical Committee will need time to arrange for their representative (s) 
to be present. 



3. 



Progress is being made in several related areas: 

BSI is proposing the creation of an ISO project for Pascal. 

Brian Wichmann is endeavouring to create a suite of Pascal test programs. 
This is an encouraging move for DPS/13, who collectively believe that 
validation suites for compilers should be provided wherever possible. 

Prof. N. Wirth is optimistic concerning our copyright problems. Springer- 
Verlag have not yet replied to my letter. 



To avoid further delaying this attention list, the following items will 
sent separately later in the month: 

1. A list of names (and where appropriate addresses and telephone numbers) 
of all people actively involved in the standardization effort. 

2. A list of other people who are being kept informed of progress. 

3. A selection of the guidelines and rules from BS:0, Part 3, which concerns 
the way in which the working group should operate. 

4. A summary of the relevant parts of "Guidelines for Approving Standards", 
which is part of a document presented by the United Kingdom to ISO at the 
Hague meeting of the programming languages sub-committee. Although this was 
not accepted by ISO, it may be necessary for BSI to adhere to its own 
requirements. 

5. Sections and sub-sections of the report which individual members of the 
working group are requested to study. Any member of the group is, of course, 
quite free to study and make suggestions concerning any part of the report. 

A.M. Addyman 
Convenor of DPS713/4. 



March 23, 1978 

Mr. Andy Mi eke 1 
Editor, Pascal News 
Computer Center 
University of Minnesota 
Minneapolis, Minnesota 



ACADEMIC COMPUTING CENTER 

THE UNIVERSITY OF WISCONSIN - MADISON 

1210 WEST DAYTON STREET 

MADISON, WISCONSIN 53706 

608-262-1166 



c-> 



55455 



Dear Andy: 



As an implementor of a PASCAL compiler as well as a "firm believer" 
in pascal's merit as a programming language, I feel compelled to comment 
on Ken Bowles' recent proposal (PASCAL News #11) to convene a workshop 
to standardize PASCAL extensions. The value of standardizing the 
extensions all implementors (including this one!) seems to add to 
PASCAL is unquestionable. However, Bowles' approach seems to me to be 
rather suspect. If this standard is to have any real value, it must 
have broad-based support in the PASCAL user community. 

Why then should the effort to produce this standard be dominated by 
organizations with a large monitary investment in PASCAL with the 
gratuitous inclusion of "a small number of academic experts" to placate 
the rest of us? Are we to believe the opinions of the average PASCAL 
devotee are less important than those of industrial and governmental 
organizations? Such an idea strikes me as rather odd given the fact 
that PASCAL has succeeded not because of these organizations, but 
in spite of them. 

Even if the composition of Bowles' workshop is made more equitable and 
broad-based, I have very serious reservations about any language designed 
by committee. It can be very strongly argued that PASCAL'S simplicity 
and elegance derives directly from the fact that it was designed by one 
man. t'Jhy not then adher to this principle? 

Bowles' workshop should by all means meet (although with a more broad- 
based composition) . Rather than drafting a specific set of language 
extensions, however, it should draft a set requirement that an extended 
PASCAL should meet. Where necessary, differences in emphasis or opinion 
should be included — all concerned parties must have a say in what they 
feel is important. These requirements should then be forwarded to a 
very small group of acknowledged language design experts (Nicklaus Wirth 
would, of course, be ideal) who would produce a single set of specific 
language changes consonant with the "spirit" of PASCAL, the state of 
the art, and the overall requirements given them. This set of changes 

would then be widely distributed, discussed and debated, but accepted 
or rejected as a whole. If they are rejected, (say by vote of the PUG 
membership) then we must acknowledge that no standardization is, at 
present, possible. If they are approved, we should accept them as the 
one and only definition of extended PASCAL. 

I realize, of course, that my opinion of how standardization should be 
done is just one man's viewpoint. However, the principle that everyone 
should have a voice in what kind of extensions should be included while 
limiting to a very few experts the decision of exactly how these 
extensions are to be specified seems a sound one. If we are to produce 
a standard, let us make every effort to ensure it is something vje can 
live with. 
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Charles N. Fischer 
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GEORGIA INSTITUTE OF TECHNOLOGY 

SCHOOL OF INFORMATION AND COMPUTER SCIENCE • ATLANTA, GEORGIA 30332 • (404) 894-3152 



April 10, 1978 



Mr. Andy Mickel 

Editor Pascal News 

University Computer Center: 227 EX 

208 SE Union Street 

University of Minnesota 

Minneapolis, MN 55455 

Dear Andy: 

I wisti to make a few comments about Ken Bowles' proposal (PASCAL News #11) 
for a workshop to develop a set of standardized PASCAL extensions. As an 
experienced PASCAL user and an implementor of a PASCAL compiler, I certainly 
agree that there are areas in which PASCAL could be improved as a systems 
programming language. There is no doubt that some standardization of exten- 
sions would be quite valuable to both users and implementors . However, I 
have some reservations about the process Bowles has proposed to develop 
these extensions. 

Having had some experience in designing programming languages, I am quite 
concerned that a set of extensions produced by a large committee might not 
be consistent with the simplicity that is one of the most attractive charac- 
teristics of PASCAL. This simplicity probably results from the fact that 
PASCAL was designed by one man. It might also be noted that while the DoD 
"Ironman" project mentioned by Bowles included input from a great number of 
people in identifying goals, the actual language design work is being done 
by small groups. I think it more appropriate that any large workshop produce 
a statement of requirements rather than a "finished" language design. 

The fact that attendance at the workshop will be restricted to a certain 
group of PASCAL users is also of concern to me. If the language to be 
produced by the workshop would end up being used by only the participants, 
this would not be objectionable. However, any extended PASCAL standard 
adopted by a group of users with considerable economic influence is likely 
to become a de facto standard. It is not acceptable for the PASCAL user 
community to have so little influence in such an effort. Further, there are 
apparently other standardization efforts under way. These should certainly not 
be ignored. 

If Bowles wishes his workshop to produce a systems implementation language 
designed by and for industrial firms and government agencies, the language 
should be given a name that does not contain "PASCAL" so that there will be no 
confusion as to its nature. If the workshop is to make a more valuable 
contribution toward the standardization of PASCAL extensions, a broader 
group of participants is necessary and more care must be taken to insure 
that the resulting language reflects the "spirit of PASCAL" and is acceptable 
to PASCAL users in general. 



Sincerely, 






7A1 Terrace D^* 
RosevUle MN 55113 USA 
March 30, 1978 



Dear Andy, 



In your recent article en Pascal Standards (PN 11 page 65), you and 
Jim point out that wany people are suggesting (and implementing) 
changes and extensions to Pascal, but few are using Pascal's design 
goals to evaluate their changes or extensions (at least few are doing 
it publicly). By referring readers to the design goals listed on the 
back cover of PN, you iffply that Pascal's design goals are 
well-understood and generally accepted* I disagree on both counts* 

* The ten-line description of Pascal's design goals is adequate for 
the back cover of FN, but it is too vague for use in judging 
proposed language features. For example, "general purpose but not 
all-purpose" is a very nice phrase which is intuitively 
appealing, but it cives little or no guidance to someone who is 
attempting to evaluate a proposed feature* If I didn't know you, 

1 would be tempted to suggest that you are purposely fostering 
confusion in this area to keep up the volume of provocative 
language proposals in PN. 

* You have been exhorting people to justify their proposals in 
terms of Pascal's cesign goals since PUG was formed (PN 5 page 
2). The fact that few people have done so seems to indicate that 
many disagree with or do not understand the stated design goals 
(or else they don't read your editorials)* 

I agree with you that any future development of Pascal, beginning with 
the Standardized Extensions that you call for, must be guided by a 
clearly-defined set of cesign goals. Discussion of Pascal's design 
goals has been remarkably absent from most material appearing in PN* I 
enclose an article which opens such a discussion* 

ity to standardize anything beyond the 
eems to have well in hand), without 
very great degree* (Doing language 
ficult, but doing it in the pages of PN 
unthinkable.) The Simula Standards 

Software Practice and Experience 1976 
essful because it has a representative 
mplementat ions . A Pascal standards 
sentative from each Pascal 
iable design group, and a committee 
e would have difficulty achieving 
dards . 

Even so, I am optimistic about the future. It will not be the end of 
the world (or of Pascal) if we fail to standardize. Pascal's greatest 
weakness (a multiplicity of incompatible implementations) is a direct 
result of its greatest strength (simplicity and clarity of 
programming). The Pascal compilers that I have seen are sparsely 
documented (to say the least), but many users have been able to modify 
the* to accept new features. Can you imagine as many people doing that 
to Fortran or Cobol compilers? 
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Richard J. LeBlanc, 
Assistant Professor 
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Implementation Notes 



PORTABLE Pascals 



CHECKLIST 

Please note the new Checklist entry number 0: DATE/VERSION. In preparation for next year, 
we encourage implementors, users, or anyone else to submit new or revised checklist 
reviews for their favorite implementations. 

Pascal Implementations Checklist 



DATE/VERSION 

(* Last checklist changes; version name or number, if any. *) 

DISTRIBUTOR/IMPLEMENTOR/MAINTAINER 

(* Names, addresses, phone numbers. *) 

MACHINE 

(* Manufacturer, model/series and equivalents. *) 

SYSTEM CONFIGURATION 

(* operating system, minimum hardware, etc. *) 

DISTRIBUTION 

(* cost, magnetic tape formats, etc. *) 

DOCUMENTATION 

(* In form of supplement to Pascal User Manual and Report ? 
Machine retrievable? *) 

MAINTENANCE POLICY 

(* How long? Accept bug reports? Future development plans. *) 

STANDARD 

(* Implements full standard? Why not? What is different? *) 

MEASUREMENTS 

(* -compilation speed (in characters /sec. please; this is a 
meaningful measurement for compilation speed); 
-compilation space (memory required at compilation time) ; 
-execution speed; 

-execution space (the memory required at execution time; 
compactness of object code produced by the compiler); 
** Try to compare these measurements to the other language 
processors on the machine, e.g., FORTRAN. *) 

RELIABILITY 

(* stability of system (poor, moderate, good, excellent); 
how many sites are using it? 
when was the system first released to these sites? *) 

DEVELOPMENT METHOD 

(* Compiler or interpreter? Developed from Pascal -P / hand- 
coded from scratch/bootstrapped/cross-compiled/etc. ? What 
language? Length in source lines? Effort to implement in 
person-months? Previous experience of implementors? *) 

LIBRARY SUPPORT 

(* Libraries of subprograms available? Facilities for 
external and FORTRAN (or other language) procedures 
available? Easily linked? Separate compilation available? 
Automatic copy of text from library into source program 
available? Symbolic dumps available? *) 



Pascal P4 



Bug Reports 



Due to a fit of oversight, I forgot to print in issue #11 Chris Jacobi's Updates 1 and 2 
to P4. They appear below. Also, there were a couple of errors in the bug list in issue 
#11. Bob Fraley caught one (see his letter below). The other error was in bug number 
(17.), in which the fix should have read: 

Replace PASCP.2826 with: 
THEN ERR0R(131); 



CO 
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Replace PASCP.2831 with: 
ERR0R(131); 



- Jim Miner 



HEWLETT m. PACKARD 

3500 Deer Creek Rood, Polo AUo, California 94304 .Telephone -415 494 -1444, TWX 9IO 373 1267 

March 22, 1978 



Mr. Jim Miner 

25 Blegen Hall 

University of Minnesota 

West Bank 

Minneapolis, Minnesota 55455 

Dear Jim, 

The fix for set declaration error checking is incorrect. In particular, if 
any error occurs, LSP is not set and therefore FSP is set to a bad value. To 
maximize error checking of uses of this type, I would suggest the following fix: 

Replace PASCP 1275 by: 

IF LSPl = REALPTR THEN 
BEGIN ERR0R(114); LSPl := NIL END 

ELSE IF LSPl = INTPTR THEN 

BEGIN ERR0R(169); LSPl := NIL END 

ELSE 

BEGIN GETBOUNDS (LSPl, LMIN, LMAX); 

IF (LMIN < SETLOW) OR (LMAX > SETHIGH) THEN 
ERR0R(169); 

END; 

This will build a "SET" type node, checking the use of variables which have this 
type. (Alternatively, set LSP: = NIL before PASCP 1271, and remove "LSPl: = NIL" 
from line PASCP 1273). 

The correction to field list, allowing ";" before the "END" of a record 
definition, is incomplete. In particular, the syntax allows null field entries 
(multiple ";" in a row). The full fix is: 

Replace PASCP 1077 by 

WHILE SY = SEMICOLON DO 
Change PASCP 1079 to: 

IN FSYS + [IDENT, CASESY, SEMICOLON] 
Change P 150 to 

IN FSYS + [SEMICOLON] 
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There is another error in P4 which causes an infinite loop when a conment 
is not closed. 

Replace PASCP 509 by 

UNTIL (CH = ')') OR EOF (INPUT); 

Replace PASCP 507 by 

WHILE (CH <>'*•) AND NOT EOF (INPUT) DO NEXTCH: 



Sincerely yours. 



RAF/hma 



Pascal P4 — UPDATEl and UPDATE2 




Bob Fraley 

Hewlett-Packarcy Laboratories 

Electronics Resfearch Laboratory 



(* Thanks, Bobl *) 



Both of these updates are dated January, 1977. They were issued by Chris Jacobi of ETH, 
Zuerich, and we printed them in issue #8. 



UPDATEl: 



Replace BOOT. 4 by: 

FOR I := ORDMINCHAR TO ORDMAXCHAR DO SOP[CHR(I)] := NOOP; 

Replace P. 477 by: 

LOAD; GENLABEL(LCIX); 

Insert after P. 479: 

GENUJPXJP(57(*UJP*) ,LCIX) ; 

Replace P. 147 by: 

BEGIN ALIGN(LSP1,DISPL); 

Replace P. 424 by: 

LOCPAR := LOG PAR + PTRSIZE; 
ALIGN(PARMPTR,LOCPAR) ; 

Insert after line PASCP. 3200: 
ALIGN (PAEMPTR, LLC 1) ; 



Replace P. 531 by: 

IF IDTYPE^.FORM > POWER THEN " 

Insert after PASCP. 3204: 

IF VKIND = ACTUAL THEN 
BEGIN 

Insert after PASCP. 3207: 
END; 



UPDATE2 : 



Implementation Notes 



FEATURE IMPLEMENTATION NOTES 

INTERm RFPORT - IiiPl RaTMIOH OF SRS - ]. 

This report addresses results of set implementation tests on three compilers, 
and a personal estimation of optimal treatment (not yet achieved anywhere so 
far). 

Professor A.H.J. Sale, 
University of Tasmania. 
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Replace P. 122 by: 

FLC := L + K - (K + L) MOD K 

Replace P. 528 by: 

CSTPTRINX := 0; 

TOPNEW := LCAFTERMARCKSTACK; 

TOPMAX := LCAFTERMARCKSTACK; 
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error 


error 


genuine, however 
1 imit should be 
big, say 256. 


set-type constraints 


0..58 


0..47 


0..47, but 
only checked 
at runtime. 


no 1 imi ts, except 
range in reasonable 
size (256 bits?) 



Note: In the ICL compiler, sets may be declared of any subrange type, and the run-time 
system will be correct as long as no element with a representation outside 0..47 
is involved. If this occurs, an "index error" is raised. (l believe this to be 
liable to lead to undetected and hibernating bugs.) 
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Burroughs B1700 

PASCAL ON BURROUGHS BI^OO 
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Dear Mr . Mickel , 

we have developed 



Pascal System for the 
Burroughs B17no/B1ROO Series. The System like many 
others is derived from the Pascal-? Compiler 
developed by VJirth and Amman at the ETH-Zuerich. 

A preliminary Version has been distributed to 
several european Universities about a year ago. 
The System is also the subject of a PhD Thesis 'in 
german . 

Unlike other B1700 Pascal systems, ours is 
implemented on top of the Bl'^00 SDL-S Langua,qe 
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which also serves as the Basis for the master 
control program and the utility software. The 
system runs on MCP-Release 6.0 and higher and is 
particularly suitable for small machine 

configurations. 

In order to remain compatible with the standard 
SDL-Architecture only emulation of realar ithmetic 
is provided. 

Current Projects include addition of 

mathematical functions and the design of an 
"ideal" Pascal architecture. 

The system has recently been redesigned and we 
will gladly distribute it to universities sending 
us a tape. (We would appreciate tapes in a 
reusable box. Installations should also indicate 
if they have use of SDL- and MIL-Compiler s) . 
Unfortunately we can not guarantee an errorfree 
system but we will eventually fix errors made 
known to us. 

Another Pascal-system was produced at our 
installation by Mr. K. Haeusermann. It uses a 
separate interpreter which emulates the 

hypothetical stack computer by Wirth and Ammann. 

Pascal systems for the B1700 have also been 
developed at many other universities (Karlsruhe, 
Newcastle, Dublin, Edinburgh ). 



Yours sincerely 



Peter U. Schulthess 
Institut fuer Informatik 
Universitaet Zuerich 
Kurvenstrasse ^^ 
8006 ZUERICH 



SWITZERLAND 



Burroughs B4700 (Fredonia) 

Georae Golden, Sr. (Computer Center; SUNY Fredonia; Fredonia, NY 14063; 716/673-3393) 
wrote on 78/4/10:. "We are trying to get Pascal running on the Burroughs B4700. It runs I 
But it takes too much core." 



Burroughs B6700 (Tasmania) 

The PASCAL compiler for Burroughs B6700/B7700 systems written at the Univer- 
sity o£ Tasmania is now available for distribution. To acquire a copy, 
fill out the attached forms and send to: 

PASCAL Support, 

Department of Information Science, 

University of Tasmania, 

Box 252C, G.P.O., 

HOBART , 7001 

The compiler is distributed on 9- track magnetic tape, (but 7-track is also 
available) and an installation manual is supplied, together with two copies 
of the user-documentation. At present this comprises: 

* Report R77-1 - a supplement to Wirth 's User Manual. 

* Report R77-3 - a Reference Manual similar to B6700 Algol's. 



* a PASCAL Language Card. 

* a PASCAL System Card. 

Further copies of the user-documentation may be available at production cost. 

The charge for the system is Australian $100 annually, and will be invoiced 
to you when you receive the tape. The tape remains our property, and should 
be returned when you have copied its contents so that future releases can be 
mailed to you. The service will cover: 

* mailing and processing costs, 

* extensions and revisions, and 

* the costs of an FTR-reporting service and maintenance. 

Each installation will be issued with FTR-forms similar to those used by 
Burroughs for use in corresponding with us, and we will attempt to do a 
professional job in maintenance of the system. 
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The Tasmania B6700 PASCAL compiler is a true compiler for the B6700 or B7700 
computer systems: it generates executable code-files which are accepted by 
the operating system. Its compilation and execution performance is within 
a 20% margin of comparable compilers in the B6700 systsm for average pro- 
grams. The current version generates LINEINFO in the code-file, but does 
not generate BINDINFO, so PASCAL programs cannot yet be linked to other 
code-files. The compiler itself is written in B6700 Algol, as are most of 
the extra trinsic procedures it uses. 

Objectives of this project were to develop a compiler which enforced compli- 
ance with the standard definition of PASCAL as far as possible by utilizing 
the special features of the B6700 system, while making it a fully integrated 
member of the B6700 compiler set. These targets have been largely met, and 
a wide variety of checks are available to the user-programmer; probably to 
a higher degree than most other PASCAL compilers. However, file attributes, 
record- oriented formatted i/o, random-access i/o, and compiler options, are 
provided in a way that will ease the learning problems of existing B6700 
programmers. The compiler permits use in a very similar manner to the well- 
know compilers (Algol, FORTRAN, COBOL, etc). 



oo 



The compiler has been stable in code for some time, reflecting its basic 
integrity. However new features are added from time to time, and notified 
to recipients as patches or as new version releases. The Department accepts 
FTR notices, and will attempt to fix those which ivarrant such attention. 
Some modifications have taken place as a result of user feedback. The 
compiler was especially designed so as not to generate dangerous code to 
the MCP, and no system crashes have been attributed to it since the first 
few months of testing, and then only three! 
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User-level documentation is provided for the compiler in the form of cards 
and reference manuals. The standard of these is similar to that of Burroughs' 
manuals and cards. Systems documentation is more sparse, and consists of 
some implementation notes, the compiler itself (a microfiche listing is pro- 
vided), and a report on aspects of the language. 

The compiler is in daily use by students at the University of Tasmania. 

I must apologize to those of you who wrote enquiring about the availability 
of our B6700 PASCAL compiler earlier and did not receive a prompt reply. 
The end of the academic year and a number of important decisions interfered 
to prevent us making the compiler available as soon as we would have liked. 

To cut a long story short, the B6700 PASCAL compiler developed at the 
University of Tasmania is now available from us. There are three conditions: 

(1) each recipient must agree not to disclose the compiler to other 
parties, and must agree not to supply copies to other institutions. 

(2) an annual fee of $100 (Australian) is required to cover mailing, 
processing, and other maintenance charges, payable to 

"The University of Tasmania". 
The compiler has been operational in a student environment at the University 
of Tasmania for a year and has proved stable and reliable; it has been 
released on a restricted basis to two other sites for about eight months 
with similar results. The compiler is provided with a Reference Manual and 
a Supplement to the User Manual (of Jensen § Wirth) , and with ready-reference 
cards. Recipients are granted copyright permission to reproduce these for 
their own purposes , and in some cases additional copies may be ordered from 
the University of Tasmania. The service provided includes the provision of 
updated versions of the compiler at intervals, and the maintenance of an 
FTR- service similar to that of Burroughs. 

If you want further information before ordering the compiler, please write 
and we can send you documentation and listings. If you want a copy, please 
arrange for the non-disclosure notice (FORM A) to be signed by a responsible 
officer of your institution and the computing centre manager (if applicable) , 
and forward it with the supplementary information (FORM B) to the address 
given . 

Yours sincerely. 



AM'^ 



CXI 10070, IRIS 80 (Paris) 



0. DATE/VERSION. 78/02/21. 



1 . Distributor/implementor/maintainer : 



implementor: 

D.Thibault 

17, rue Gay-Lussac 

F-75005-Paris 



distributor/maintainer: 

P.Maurice 

Universite Paul Sabatier 

Informatique 

118, route de Narbonne 

F-31077-Toulouse-cedex 

(61)53-11-20(300) 



2. Machine : CII-10070,CII-HB-IRIS 80,XDS-Sigma 7 

3 . System configuration : Siris7,Siris8. Easily available on other systems: 
adaptation of run-time routines and perhaps of the code-generation phase of 
the compiler. 

4. Distribution : source programs (Pascal and assembly code), object programs 
and load modules available on magnetic tape (9 tracks,1500bpi);send a mini- 
tape to distributor; mailing cost only: 

5. Documentation : user manual, in french (sept. 75);separate papers describe 
extensions and differences with the User Manual and Report (K. Jensen, N. Wirth) ; 
not machine retrievable. 

6. Maintenance policy : bug reports are encouraged ;announcements of releases 
are sent to users, together with listings of modifications (errors and/or 
extensions). Release 5 has been issued in Jan. 78. 



7. Standard: 



QQ^_lQ)Bl§l]?§Qt§^- 



type T= ' 
record . 



•type identifier> 
. case <type id> of 



extensions: 



8. Measurements: 



(tag field is mandatory) 

- structured types of files. 

- separate compilation 

- VALUE part for global variable" initialization 

- heap management through NEW/DISPOSE or NEW/RESET 

- standard files TTYIN,TTYOUT used for interactive 
applications programming 

- compiler options (source listing, run-time checks, 
post mortem dump, pseudo-assembler listing of ge- 
nerated code. 

compilation space: minimum 32K words; 

40K words to compile the compiler, 
compilation speed: ^ 2100c/s (Fortran: * 1300c/s) 
execution speed: programs from N.Wirth(ETH Zurich, March 76): 



Professor A.H.J. Sale, 

Department of Information Science . 





Pascal 
run-time checks 


Pascal 
no checks 


Fortran 


palindromes 


4260ms 


3860ms 


2970ms 


powers of two 


1530ms 


1470ms 


3867ms 


prime numbers 


1900ms 


1700ms 


941ms 


count characters 
in a file 


5100C/S 


5800C/S 


5100C/S 
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9. Re1 iabil i ty : good;used since 1974 in 2r25 installations, mainly for teaching 
programming and compiler writing, and also for the development of large system 
software projects. 

10. Development method : fully bootstrapped from Amman's CDC compiler;generates 
code for the CII link editor;all operating system dependencies are located in a 
monitor ('='2000 lines of assembly code), which must be linked with user programs. 
The compiler takes advantage of the separate compilation system: it consists of 
four overlayed modules (~8500 'pretty-printed' Pascal lines). 

The bootstrap process took about 2 man/years, to produce a compiler for the first 
version of the language(Wirth 71) ;adaptation to standard took about 6 man/months. 

11. Library support : a system library contains the standard Pascal functions SIN, 
COS,. . . and the Pascal monitor (see 10). 

Separate compilation allows using private libraries, written in Pascal or in any 
other language; interfacing with other languages requires a knowledge of the com- 
piler. 

Programs are manipulated under control of a 'Pascal programming system', which 
provides the users with powerful editing functions, ranging from source inclusion 
to program transformations. Also provided are interactive debugging at compile and 
execution time, and library management. The system is entirely written in Pascal 
(^22000 lines). 

Coiranodore 6502. 

Formerly MOSTEK. See DEC LSI-Il (San Diego). 



Computer Automation LSI-2, 4 



Bob Hutchins (Computer Automation; 18651 Von Karman; Irvine, CA 92713; 714/833-8830x335) 
wrote on 78/3/1: "We just recently brought up sequential Pascal on out new 16-bit 
minicomputer series, the Naked Mini-4 series. It runs on all models including the NM-4/10 
which sells for $645 including CPU, 4K RAM, and 4 I/o ports. As far as I know, this is the 
lowest priced minicomputer system that supports Pascal. Our Pascal is based on sequential 
Pascal supplied by Brinch Hansen. It is supplied at a one time fee of $900 including 
compiler, interpreter, and documentation." 

Minicomputer News reported on page 2 of their Jan. 5, 1978, issue that "Pascal software 
[on the LSI-4 line] , formerly priced at $900, will be offered without charge." 



Data General ECLIPSE (San Bernardino) 



MEDICAL DATA CONSULTANTS 

March 10, 1978 




(714) 825-2683 



1894 Commercenter West, Suite 302, San Bernardino, CA 92408 

Dear Andy, 

We have spent the last several months in a reconsideration 
of our entire PASCAL endeavor. As we reported previously, we 
have developed a new version of Data General compatible PASCAL 
which is significantly faster than our previous version, but 
which continues to use a 64-bit data path, is fully RODS 
compatible and easily modifiable and extendable. We had 
previously intended to take this version to market as a low 
priced, but profit making venture, as reported in the February 
PASCAL NEWS. 



As part of our continuing PASCAL development we now have a 
preliminary implementation of a PASCAL compiler which produces 
code that executes at the speed of that provided by Data 
General's Optimizing FORTRAN 5. We expect, however, the full 
development of this product will take 6-12 months. 

\'ie have decided, therefore, to release our current improved 
version of Data General PASCAL for a reproduction cost of 
$100.00 on 800 BPI, 9 track magnetic tape. This includes 
executable object code, source code and machine readable 
documentation. 

Please find attached a standard description of the product. 

Sincerelv 
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Ted C. Park 

Director, Systems Development 

DISTRIBUTOR/IMPLEMENTER/MAINTAINER 

Ted C. Park 

Director, Systems Development 

Medical Data Consultants 

1894 Commercenter West 

Suite 302 

San Bernardino 

CA 92408 

MACHINE 

Data General - any ECLIPSE- line computer 

SYSTEM CONFIGURATION 

ECLIPSE must have FPU or EAU 
Minimum of 16K words user memory 
RDOS REV 6.1 or 6.2 
FORTRAN 5 (any recent revision) 

DISTRIBUTION 

System supplied on 9-track 800 BPI tape in RDOS 'dump' format. 
The cost is $100.00 to cover our mailing and duplicating costs. 

DOCUMENTATION 

User must obtain his own copy of the Pascal Users Manual and Report . 
It is recommended that the user obtain an implementation kit from 
the University of Colorado. 
Documentation and operating procedures are supplied on the tape. 

MAINTENANCE POLICY 

Bug reports are welcome but no formal commitment for support can be 
made at this time. To date, no bugs have been reported. 

STANDARD 

PASCAL P4 subset 
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MEASUREMENTS 



Compilation Speed: 
Word Size: 
Real Arithmetic: 
Integer Arithmetic: 
Execution Speed: 
Minimum Memory Needed: 
Virtual Memory Required: 



50 chars/sec (including blanks and comments) 

64 bits 

Uses 64 bits 

Uses 32 bits 

Fairly slow (since it is interpreted!) 

16K words 

A contiguous disc file of 524,288 bytes 



RELIABILITY 



Version 1 exists in at least 10 sites, we believe no bugs exist. 
Version 2 is primarily the same as Version 1 except with improved 
operating procedures, faster compiles and executions, and increased 
capability. As such we anticipate few, if any, bugs. 

DEVELOPMENT METHOD 



Below is tlie checklist inforiaation on our P^SCAL compiler for 
Data General NOVA (or equivilent) computers. 

DISTRIBUTOR/IMPLEMENTOR/'IAINTAINER — RIIINTEK, IPJC; Box 220; 
Columbia, Md. 2104 5 (301) 

riACHiriE — Data General NO^^A or ECLIPSE minicomputers or 
equivalents. 

SYSTEM CONFIGURATIOM — Mapned RDOS system or 32K unmapned RDOS 
vzith minimum operating system. The current revision of Data 
General RDOS will be supnorted but the compiler sliould v7ork with 
older levels. 

DISTRIBUTION — 9 track magnetic tape, 800 BPI, 7.5 inch tape 
in the RDOS dump format. Price for a single user license is $975. 
Multi-use, OEM's, and educational licenses v/ill >)o handled on a 
separate basis. 






CO 



Developed from PASCAL-P4. P-CODE assembler and interpreter written 
in assembly language. All programs are extremely modular and well 
documented so that any changes wished by the user should be easy to 
incorporate. 

LIBRARY SUPPORT 

No Data General libraries are needed to run the system nor is it 
possible to use any if desired. 



Data General NOVA, ECLIPSE (Columbia) 




Rhiiitek, Inc. 



Connputer Engineering 



P.O. Box 220, Columbia, Maryland 21045 



March 8,19 7g 



DOCUMENTATION — The package includes source code, binarv code, 
and ready to run demo programs. Instructions for executing the 
compiler are included; the operational information can be 
obtained from, the books b^'' Per Brinch Hansen and Al Ilartman. 

MAINTENANACE POLICY — Updates for one year and notification of 
su.>)stantial enhancements as long as interest is shown. -Je v/ill 
maintain a users group and encourage bug reports and suggestions. 

STArJDARD — Based on Sequential PASCAL written by Per Drincli 
Hansen and Al Hartman. The current version lacl^s : "file, goto, 
label, and nacked" reserved \rards and sqr, sin, cos, arctan. In, 
exp, sqrt, eof, eoln, odd, and round built in functions. ^:his 
is a seven pass Sequential PASCAL compiler wr-itten in PASCAL and 
generating code for a h^^pothetical 'stack' m.achine. ^he code is 
internreted b^^ a urogram, -/ritten in NO^A assembly languacre. 

MEASUREMENTS — The compiler compiles source code at the rate of 
200 line/nin. This is about one-half o^ the rate of the PDT^ 11/45 
hut five to ten times the speed of the other compilers on the 
NOVA. The com.piler will compile itself in a':>out' 30 minutes total. 



RELIABILITY 



good 



DEVELOP^-IENT METilOD — The virtual machine interpreter was coded 
in NOVA assembly language and then the compiler ^-/as modified 
along with interpreter into its present form. 

LIBRARY SUPPORT — ^:'here is no library support as yet. The 
operating programs supoort program swanning or chaining with 
only minor effort as this is used with" the comnilor. 



GO 



Dear Andy, 

RHINTEK, Inc. is making availa})le its PASCAL compiler to other 
Data General NOVA/ECLIPSE users. This compiler is used by 
RHINTEK as an application and system nrogramming language and 
will continue to receive support and enhancements by us. We 
are using the compiler on a NO^^^a 3/D running Rev. 6.10 mapped 
RDOS. However, wo are cleaning up the code and expect the 
compiler to be able to run under unmapped RDOS on a 32k NOVA 
within a few weeks. 



Sincerely, 



£.;... %^' 6 



}-Va/vo 



Rainer McCown^ /^^.^ch-nJ: 
Rhintek, Inc. 
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DEC PDP-11 (Berkeley) 



A package of UNIX software is available from the Computer Science 
Division of the University of California at Berkeley. This package includes the 
instructional Pascal system which has been in use at Berkeley this past year 
and the standard Berkeley editor ex, an extension of the standard UNIX editor 
ed which offers many new and improved features. The Pascal system requires 
separate I/D space to run (an 11/45 or 11/70) ; ex will run without separate 
I/D but requires a full load of user core (64 bytes). 

UNIX Pascal is designed for interactive instructional use. It produces 
interpretive code, providing fast translation at the expense of slower execution 
speed. An execution profiler and Wirth's cross reference program are also 
available with the system. The systems supports full Pascal, with the exception 
of procedure and function names as parameters. The language accepted is very 
close to 'standard' Pascal, with only a small number of extensions for the 
UNIX system. (An option restricts the implementation to the standard.) 

The UNIX Pascal User's Manual gives a list of sources relating to the 
UNIX system, the Pascal language, and the UNIX Pascal system. Basic usage 
examples are provided for the Pascal interpreter components pi, px, and pxp. 
Errors commonly encountered in these programs are discussed. Details are 
given of special considerations due to the interactive implementation. A number 
of examples are provided including many dealing with input/output. An appendix 
supplements Wirth's Pascal Report to form the full definition of the UNIX 
implementation of the language. 

Source code, binaries and machine readable versions of all documentation 
are included with the tape. The Pascal system and the ex text editor are 
distributed under a license agreement; UC Berkeley is thus the sole source for 
this software. The software is distributed only to UNIX licensees and only 
for non-commercial purposes. A copy of the cover page of the UNIX license 
agreement is an acceptable form of proof of license. 

The distribution tape is a standard "tp" format, 800 BPI magnetic tape. 
A 1200 foot reel is the minimum and preferred size. There is a one time $50 
charge ($65 for overseas airmail) for a copy of this tape. This charge includes 
the costs of preparing the tape, mailing costs, and the costs of distributing 
future updates and corrections to the programs and documentation on the tape. 
These updates and corrections will be distributed at regular intervals as 
their volume and severity warrants. Also included with the tape are high 
quality copies of the UNIX Pascal User's Manual and the Ex Reference Manual 
which require a phototypesetter to produce. It is also possible to obtain a 
copy of the documentation without getting a copy of the tape. The $5 charge 
for this copy may be deducted from the tape charge if you later decide that you 
want a tape. If you prefer, you may send an additional $10 and we will purchase 
a tape on which to send you the software. 

To receive a copy of the license agreement (which must be signed before 
you can receive the tape) write to: 

Berkeley UNIX Software Distribution 

c/o William N. Joy 

Computer Science Division 

Department of EECS 

Evans Hall 

University of California, Berkeley 

Berkeley, California 94720 

Questions about this tape can be directed to William Joy at the address above 
or at (415) 642-4948. Messages can be left at the Computer Science Division 
office phone (415) 642-1024. 



DEC PDP-11 (Stockholm) 



0. DATE/VERSION. 77/12/22. 
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DEC PDP-11 (OMSI) (formerly ESI) 



0. DATE/VERSION. 77/12/26; "OMSI Pascal-1" (formerly "ESI Pascal"). 

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Oregon Minicomputer Software, Inc. (OMSI); 4015 SW 
Canyon Road; Portland, OR 97221; 503/226-7760. Implementors: John Ankcorn, Don Baccus, and 
Dave Rowland. 

2. MACHINE. Any model Digital Equipment Corp. PDP-11 or LSI-11. 

3. SYSTEM CONFIGURATION. Minimum of 16K words. Operates under RT-11, RSTS/E, or RSX. 

4. DISTRIBUTION. Compiler, support module, cross referencer, text editor and instruction 
manual available for $1500 ($995 for educational use). Available on 9 track 800 bpi 
magnetic tape, or DEC cartridge disk. 

5. DOCUMENTATION. Over 70 page machine retrievable instruction manual. Currently 
(76/11/02) working on more. 

6. MAINTENANCE. One year of unlimited fixes and updates, followed by annual subscription 
service. (* Reported by users that "vendor seems to be responsive in terms of support". *) 

7. STANDARD. Full standard plus extensions: additional features for real-time hardware 
control; separate compilation of procedures; Macro (assembler) code in line insertion; 
actual core addresses of variables can be fixed (giving access to external page I/O 
addresses at the Pascal level. 

8. MEASUREMENTS. 

compilation speed — About 3500 characters /second, on the PDP-11 model 05. 

compilation space — very economical-it can compile 3000 line programs in 
28K on PDP-11/40. No overlays are used in the system. 

execution speed — about twice as fast as the DEC FORTRAN IV and many times 
faster than DEC BASIC. A worst-case 'number-cruncher' 
example ran at 40% faster than the DEC original FORTRAN. 

execution space — very economical-much of the space improvement over DEC 
FORTRAN is due to the smaller support module for Pascal. 

9. RELIABILITY. Excellent— far better than DEC FORTRAN. In use since 75/11. Over 60 
installations, and growing steadily. 

10. DEVELOPMENT METHOD. Single pass recursive descent compiler written in Macro-11. 
Hand-coded based on University of Illnois bootstrap (with extensive changes) in about two 
person-years of effort. First compiler written by both implementors. Compiler translates 
source into Macro-11 which is then assembled and linked to the support module for 
execution. 

11. LIBRARY SUPPORT. Separate compilation of procedures with load-time insertion and 
linkage is implemented. 



DEC VAX-1 1/780 

0. DATE/VERSION. 78/03/27. 

1. Implementor/Distributor/Maintainer . 

Implementor: Professor Hellmut Golde 

Department of Computer Science 
University of Washington 
Seattle, WA 98195 
Tel. 543-9264 (Area Code 206) 

2. Machine: DEC VAX-11/780 in native mode. 

3. System Configuration ; DEC VAX-11/780 under the VMS Operating System. 

10. Development Method : 

The compiler will be derivative of the CDC 6000/CYBER compiler. 

The compiler will be transported to the VAX system via cross-compilation. 

Hewlett Packard HP-2100, 21MX (Trieste) 



Paolo Sipala (Istituto di Elettrotecnica; Universita di Trieste; Via Valerio, 10; 
TRIESTE; Italy) wrote on 78/03/20: 
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I have recently completed a Pascal-S compiler/interpreter for the HP 2100/21MX computer, 
running under DOS-IIIB. I enclose the Documentation Form accompanying the submission of 
the program to the Hewlett-Packard Software Center, Contributor Section (11000 Wolfe Rd.; 
Cupertino, CA 95014), through which the program should be available for distribution in 
the near future. 

To summarize the data in the form, the system requires a llK main core area (so it might 
fit into a 16K system, if the resident DOS modules are kept to a minimum, but 24K is more 
comfortable); there are separate versions for non-EAU, EAU, and floating point options 
machines. It is not noticeably slower than the standard compilers while compiling, and not 
worse than the standard interpreter (Basic) while interpreting. It has been subjected to 
rather limited testing (a few dozens programs from the Pascal Manual) and is being now 
offered to students here for their exercises. 

Until the program becomes available through HP Software Contributors Center, I might send 
a copy of the program to those who request it by enclosing the price of the mailing (the 
weight is about 2 lbs.). 



Hewlett Packard HP-3000 



DATE/VERSION. 78/04/15. 



1. DISTRIBUTOR: The system is available in the HP-3000 Contributed Library, 
Volume 4. Contact your local sales office, or write: 
Hewlett-Packard Company 
Contributed Software 
P.O. Box 61809 
Sunnyvale, CA 94088 

IMPLEMENTOR: Robert A. Fraley 

Hewlett-Packard Laboratories 
3500 Deer Creek Rd. 
Palo Alto, CA 94304 
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MAINTAINER: Maintenance is not provided, but errors may be mailed to the 
implementor. 

2. MACHINE: HP-3000. 

3. SYSTEM CONFIGURATION: MPE. 

4. DISTRIBUTION: The system will be available through the HP-3000 Contributed 

Library in June, 1978. 

5. DOCUMENTATION: Sparse machine-readable documentation is included. 

6. MAINTENANCE: None. Error reports may be sent to the implementor, and may be 

fixed in later releases. Full file support and separate procedure compilation 
may be available in a future release. 

7. STANDARD: Falls short of the standard due to the sorry state of the P-compiler. 

Measures are being taken to improve the P-compiler. 

8. MEASUREMENTS: No specific measurements made. Some improvement will be available 

in a future release. The compiler is somewhat awkward to use, due to the 
P-code intermediate. Compilation and link-edit of the compiler operates at 
125 lines per minute. 

9. RELIABILITY: Good. Currently in use at nine installations. 

10. DEVELOPMENT METHOD: Bootstrapped from a P-compiler by Grant Munsey, Jeff Eastman, 

and Bob Fraley. Compiles to HP-3000 machine code. 

11. LIBRARY SUPPORT: None yet. 



IBM 360/370 (Australia) 



will meet all of her expectations 
on the system. 



and we look forward to hearing her comments 



Cox/Tobias letter(s). 



AUSTRALIAN ATOMIC ENERGY COMMISSION 

NUCLEAR SCIENCE AND TECHNOLOGY BRANCH 

RESEARCH ESTABLISHMENT, NEW ILLAWARRA ROAD, LUCAS HEIGHTS 



TELEGRAMS: ATOMRE, SYDNEY 
TELEX: 24562 

TELEPHONE: 531-0111 

IN REPLY PLEASE QUOTE: J^f^.mwb 



ADDRESS ALL MAIL TO: 

AAEC RESEARCH ESTABLISHMENT 

PRIVATE MAIL BAG, SUTHERLAND 2232 

N.S.W. AUSTRALIA 



13 March, 1978. 



Dear Andy, 

Just a note to let you know the current status of Pascal 8000 for 
IBM360/370 computers. 

We are currently distributing version 1.2 of the system. The 
differences between 1.2 and our earlier 1.1 distribution include a few 
bug fixes (there were some installation problems on VSl) , and a few 
new features, such as the inclusion of the characters _,, [J,&f | and-n. 
We are very happy with the reliability of the system, - this too has now 
gone from very good to excellent. We very much enjoy the reports received 
from Hal Perkins at Cornell University. His letters to us are somewhat 
overwhelming (average - 10 pages) , and we really appreciate his feedback. 
We only wish more sites would drop us a note as to their progress. 

We have now shipped a system to Judy Bishop at the University of the 
Witwatersrand, and we enjoy corresponding with her. We hope that Pascal 8000 



Judy passed on your thoughts of setting up an American distribution centre; 
we somehow feel that this may cause more problems than it is worth. We cannot 
understand why people in the U.S. are afraid to contact us directly - perhaps 
they doubt that Australia has an adequate postal system (no, letters are not 
delivered in the pouches of kangaroos) . We had some delays in the processing 
of orders earlier in the year, mainly due to our deciding to drop the non- 
disclosure agreement. We have since established a rather smooth distribution 
setup and have involved another person to handle the answering of correspondence, 
mailing of tapes, etc. We answer all initial enquiries with an order form and 
a copy of our Reference Manual; on receipt of the order form, we despatch the 
system and invoice the organisation for $A100 at a later date. The time from 
our receiving an order form to despatching a system should be no longer than 
five days, i.e. the system should be in the recipient's hands three to four 
weeks after they post their order, provided there are no unforeseen delays. 
We feel that this is not an unreasonable period of time. 

We see a number of problems arising if we were to establish alternative 
distribution centres - who supplies and copies the tapes, who prints the manuals, 
who fixes the bugs, who answers technical questions, who supplies the updates, 
and so on. We are, however, willing to hear of any strong arguments supporting 
such a centre. 

We now have 40 Pascal 8000 sites operational; those on Version 1.1 
automatically received the updates to bring them up to 1.2. We anticipate 
more orders as a result of our dropping the non- disclosure agreement. We 
are planning a Version 2, but cannot anticipate its release. 

We have sent a copy of our latest Reference manual to you under separate 
cover to add to your undoubtedly desk-high pile of manuals. We hope you find 
it of interest. 

And finally, let us say how much we appreciate your efforts in the Pascal 
Users Group, and your words of encouragement for Pascal 8000. 

Best regards. 



^-^%^ 



Gordon Cox 

Jeffrey Tobias 
Systems Design Section 



Intel 8080 (Ann Arbor) 



Jim Rogan (Comshare; Wolverine Tower; 3001 S. State St.; P.O. Box 1588; Ann Arbor, 
Michigan 48106; 313/994-4800) wrote on 78/2/16 that Comshare "can currently cross-compile 
[Pascal] source for the Sigma 9 and an INTEL 8080 machine." 



The following is an overview of COMSHARE'S PASCAL compiler system. It 
is presented and outlined with respect to a "package" that could be de- 
livered, from which you could implement the system on your machine. 
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I. History 

Comshare's PASCAL compiler was originally a bootstrapped version 
of the portable Pascal 'P' compiler. The impetus for the compiler project 
was to provide the company programmers v/lth a state-of-the-art language 
from which they could write readable, ea'^iTy maintainable, efficient 
programs. Along with these objectives, machine independent programs were 
sought and this feature v/as designed into the compiler system. It was 
decided that the portable PASCAL compiler, with some major modifications 
would be a reasonable base to start from. 



II. PASCAL Language Modifications 

In areas where the language definitions were found undesirable or 
inadequate, modifications were made. The areas primarily effected were 
the I/O and scoping structure. In brief, the standard INPUT and OUTPUT 
files were eliminated along with the GET and PUT operations. They wey^e 
replaced with 'FILE' declaration types, OPEN and CLOSE primitives. The 
READ and ViRITE statements were modified and binary file operators were 
added. 

Also, the scoping mechanism was eliminated (ie. all procedures are 
considered on the same "level") because it was contrary to structured program- 
ming principles, allowing for pathelogical data references, etc. All the 
basic language statements, control structures and the declaration sections 
are the same or enhanced. 



IV. Compiler Specifications and Limits 

Aside from our current, and most highly recommended compiler, we 
have available two predecessors from which it evolved. A list of pertinent 
facts relating to each version follows. All timing estimate;; are based 
relative to our XDS 1968 FORTRAN compiler which is a one pa:-:- processor 
written in a low-level language. 

A. PASCAL THREADED -CODE INTERPRETER 

This version implements the language essentially as described in Jensen 
and Wirth's User Guide / Report. 

- uses the ETH character set. 

- no external procedures. 

- generates macro's that are assembled into 
threaded calls to runtime interpreter. 

- very limited I/O facilities. 

- do not know the specific core requirements 
but I'm sure it's no oroblem. 

- runs at approx. 10.0 times the soeed of 
FORTRAN. 
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Note: 



Since the language has become an off-color PASCAL, 
the name has been changed to PASTEL. 



III. Operational Characteristics 

A. System design 

Comshare's PASTEL compiler is a three phase (pass) language processor 
system. The first phase is a machine independent phase, the second and 
third are target machine dependent. The process basically consists of 
translating a source program into a machine independent intermediate form 
of code for a hypothetical stack computer (see "The PASCAL <P> Compiler: 
Implementation Notes", NORI, AMMANN, JENSEN, WIRTH). Then, for any given 
machine, a code generator for it converts the intermediate code into hard 
machine code. 

The first phase (compiler) has three functions: to syntatically 
analyze the source program; to translate the program into a form of 
"assembler-like" intermediate instructions (P-codes) and directives; and 
finally to perform the static and dynamic data allocation. 

The second phase also has three discrete functions: to translate 
the P-codes into a form suitable for code emission (triples) and optimi- 
zation; optimization, and the emission of the machine instructions them- 
selves. 

The third phase is necessary for portability purposes. It is simply 
running the target machines assembler over the generated symbolic instruction 
to produce a loader compatible relocatable binary object file. The process 
can be viewed as follows: 

Please note that for the ultimate "production" compiler, one would 
want to eliminate the third phase by adding a module to the code generator 
to emit relocatable binary directly. The emission of the symbolic meta 
symbol could then be an "optional" feature for the compiler to aid in 
analysis and debugging of the systems you apply this language to. 



B. PASCAL COMPILER 

This is a "real" compiler in the sense that all interpreter functions 
were eliminated and replaced with a code generation phase. The general 
enhancements are as follows: 

- uses EBCDIC character sets. 

- augmented P-code set. 

- I/O still limited but faster. 

- full set of data types. 

- stack machine operations are simulated 
in registers where possible. 

- maximum core requirement is approx. 
40K words (??). 

- language complement is 'very close to 
"standard" PASCAL. 

- runs at approx. 3.0 times the 
speed of FORTRAN. 

C. CURRENT PASTEL COMPILER 

This compiler is wery close to our version of a finished product. 
It has a lot of enhancements in the areas of usability, efficiency and 
machine independence. It contains user-oriented features, a new and op- 
timizing code generator and cross-compile abilities working for a Sigma-9 
and an INTEL 8080 micro computer. Its language and feature descriptions 
can be reviev/ed in the enclosed preliminary reference manual. They are 
highlighted by: 

- compiler option recognition. 

- language processor control program. 
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- full complement of I/O facilities that 
are very efficient. 

- external non-PASTEL procedure linkage. 

- dynamic arrays. 

- static and dynamic data allocation. 

- packed data structures and data 
allocation options. 

- a manual . 

- very good documentation (in English) 
of the internals. 

- 'LOOP' statement. 

COMPILER: 

source language is PASTEL and is 
approx. 6600 lines of code + 
comments; object size is 31K v/ords; 

CODE GENERATOR: 

source language is PASTEL and is 
approx. 2900 lines of code + com- 
ments; object size is 17K v/ords; 

RUNTIME: 

source language is meta-symbol with 
a little PASTEL and is relatively 
small in size; requires 1 .8K words of 
core for code + storage buffers. 

- runs at approx. 1.5 times the speed of 
FORTRAN. 

- good testing procedures for releases of 
new versions. 

V. Implementation Considerations (MACHINE X) 

1. Must develop a code generator targeted for your specific 
machine. This would basically involve modifying the 
code emission routines within our "skeleton" code 
generation phase processor. 

2. A runtime must be developed to support the emitted calls 
for I/O and a few miscellaneous functions. The runtime 
is approximately 90% I/O routines interfacing with the 
operating system, 6% house keeping routines and the 
remainder consists of miscellaneous system functions to 
support language features. These routines could be 
written in PASTEL and developed concurrently with the 
code generator using COMSHARE timesharing services or, 
could be done on your given system in any language 
desired. 

3. The compiler "process controller" will need some minor 
changes to do the appropriate subprocess start-up, 
termination and communication control. 

4. Modifying the code generator mechanisms to incorporate 
the new procedure calling protocol for interfacing with 
non-PASTEL languages. 



Ml. Implementation Considerations (XEROX SIGMA 9) 

1. The compiler and code generator can be directly assembled by 
the meta-symbol processor, since they are coded in PASTEL. 

2. The runtime will need some modifications for interfacing with 
CPV. These changes should be strictly limited to the I/O in- 
terface. Our system does not have a 'DCB' concept and it would 
be necessary to install these into the runtime to do the physical 
data transfers. All the other code is in the Sigma-9 instruction 
set and PASTEL. 

3. The process controller will need some re-writes to do the appro- 
priate subprocess startup, termination and communication. 

4. Modifying the code generator to incorporate the new procedure 
calling protocol for interfacing with external, non-PASTEL lang- 
uages. 



Intel 8a80 (Munich) 



1 . Implementors : 

D. Krall, W. Remmele , U. Weng 

Siemens AG 

ZT ZFE FL SAR 121 

Otto-Hahn-Ring 6 

D-8000 Munchen 83 

Germany 

2. Machine: 

Intel MDS800 (under ISIS II) with 8080 processor; 
Host-machine: Siemens 4004/151 (or any with a Pascal-system) 

3. System configuration: 

64 K Byte RAM, Floppy Disk, Console; 

A possibility to transport the intermediate code from the 

host-computer to the MDS. 

4. Distribution: 

No final decisions made yet - contact implementors. 

5. Documentation: 

A manual is available (written in German). Updating is done 
with each new version. 

6 . Maintenance : 

No final decisions made yet . 

7. Standard: 

No changes to the Standard. The attribute packed is ignored. 
Current restriction: No functions as parameters. 
Extension: external procedures. 

8. Measurements: 

No measuring has been done yet . 
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9. Reliability: 

Seems to be excellent: No known errors. 

10. Development method: 

Compiler derived from ETH's P4; new Assembler, Linkage-Editor 
and Interpreter. A resident version for the MDS800 is in work. 
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Interdata 7/16, 8/32 



Northwest Microcomputer Systems 85/P 



Mai'iiicliip Sij.steni.s 

computer hardware and software 

16 Saint Jude Road 

Mill Valley, Ca. 94941 

(415) 383-1545 



March 22, 1978 



Timothy M. Bonham 
D605/1630 S. Sixth Street 
Minneapolis, MN 55454 

Dear Tim: 



The many extended conversations that went on at the Computer. F aire resulted 
in some scrambled information being received. The Interdata 7/16 Pascal 
compiler that I have a copy of is the cross-compiler for the Univac 1100 
that was done by Mike Ball of the Naval Ocean Systems Center (formerly 
Naval Undersea Center) in San Diego, His compiler is a version of the 
Hartmann / Brinch Hansen compiler with the interpretive code generation 
pass removed and three phases added which generate Interdata machine code. 
He has both the Sequential and Concurrent compilers running (with common 
code generators) , and an Interdata kernel for Concurrent Pascal. The 
compiler was written with "source code configuration" statements in it 
so that either a Univac or an Interdata version can be generated by 
processing a common soxirce with a Pascal program. As of the time I got 
a copy of the compiler (about a year ago) , only the cross-version was 
running, and the bootstrapping to the 7/16 was not yet complete, I have not 
talked with Mike to find out whether the compiler is yet running on the 
7/16 itself, I do know that the Univac version was producing workable 
7/16 code, 

I understand that Mike now has the Interdata 8/32 version compiling itself on 
the 8/32, Apparently the 8/32 version is extended beyond the original 7/16 
design, and may be moved back down to the 16 bit series. In any case, 
the person to contact about all this stuff is Mike, not me. (Mike is a PUG 
member, and his address is listed in the roster) . 

I got a copy of Mike's compiler in the hopes of using it as a base to build 
a true compiler for the. T.I. 9900 machines I am building. At present, we 
are taking a hydra-headed approach to Pascal, We are looking at the UCSD 
Pascal, and also at bootstrapping the original Concurrent Pascal via the 
interpretive code. Once we have a workable interpretive Pascal, we will do 
the true compiler if we feel the need, 

I hope this information has been of use, I will send in an implementation 
checklist for my 9900 Pascal as soon as it is running. 



Sincerely, 




Northwest Microcomputer Systems (121 East 11th; Eugene, OR 97401; 503/458-0626) is 
marketing an Intel 8085A based system which supports UCSD Pascal — see DEC LSI-11 (San 
Diego), Hardware includes two floppy disks (1 megabyte), 54K bytes of 450ns static RAM, a 
keyboard, 24 by 80 char CRT, 2 serial ports, and several parallel ports. The price is 
$7495. Also included is the CP/M operating system. 



Prime P-400 
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0. DATE/VERSION. 78/03/01. 



GEORGIA TECH PRIME 400 PASCAL COMPILER. 



1. IMPLEMENTOR /DISTRIBUTOR: 

Professor Richard J. LeBlanc 
School of Information and Computer Science 
Georgia Institute of Technology 
Atlanta, Georgia 30332 

2. MACHINE: PRIME 400 

3. SYSTEM CONFIGURATION: PRIMOS IV Operating System, 64V mode, 128K 

bytes minimum. 

4. DISTRIBUTION: A first release of the compiler should be available 

by July 1978. Further details are not yet finalized, 

5. DOCUMENTATION: None yet available beyond PASCAL-P documentation, 

6. MAINTENANCE POLICY: Error reports from users will be encouraged. 

Details concerning distribution of corrections and updates 
not yet finalized. 

7. LANGUAGE IMPLEMENTED: PASCAL-P subset of Standard PASCAL. 

8. MEASUREMENTS: Not yet available. 

9. RELIABILITY: Not yet available. (It is intended that this 

implementation project will eventually result in a highly 
diagnostic and very reliable compiler.) 

10. DEVELOPMENT METHOD: The code generation parts of the PASCAL-P4 

compiler are currently being rewritten to generate PMA calls 
to interpreter routines. This will then be assembled and 
linked with those routines , producing a "threaded code" 
interpretive program. The compiler will be bootstrapped 
to the PRIME using PASCAL-6000 on a CDC CYBER 70. 

11. LIBRARY SUPPORT: None yet available. Support for external 

procedures written in PASCAL, FORTRAN and PMA will be an 
early addition to the compiler. 

12. FURTHER DEVELOPMENT: As soon as this first version is available, 

work will begin on adding code generators to produce directly 
executable code. At the same time, implementation of full 
PASCAL will be under development. Many of the diagnostic 
features currently found in the UW-PASCAL compiler for 
UNIVAC 1100 machines will also be included. 
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John Walker 



INDEX TO IMPLEMENTATION NOTES 



General Information 



#9&10: 60. 
#11: 70. 



Checklist 



//9&10: 60. 
#12: 56. 



Portable Pascals 



Pascal-P 

#9&10: 61-62. 

#11: 70-72. 

#12: 56. 
Pascal Trunk 

#96el0: 62. 
Pascal J 

#9&10: 62. 



Pascal Variants 



Concurrent Pascal 

#9&10: 63. 

#11: 72-74. 
Modula 

#9&10: 63. 

#11: 74. 
Pascal-S 

#9&10: 63. 

#11: 72. 



Feature Implementation Notes 



Sets 

#9&10: 64-66. 

#12: 57. 
For Statement 

#9&10: 66-69. 

#11: 79-80. 
Default Case 

#9&10: 69-70. 
Variable Parameters 

#9&10: 71. 
Interactive I/O 

#9&10: 71-72. 
Unimplementable Features 

#11: 75. 
Long Identifiers 

#11: 78-79. 
Boolean Expressions 

#11: 76-78. 



Machine Dependent Implementations 



Alpha Micro Systems AM-11 

See DEC LSI-11. 
Amdahl 470 

See IBM 360, 370. 
Andromeda Systems 11-B 

#11: 80. 
Burroughs B1700 

#9&10: 73. 

#12: 57. 
Burroughs B3700, B4700 

#9&10: 73. 

#12: 58. 
Burroughs B5700 

#9&10: 74. 

#11: 81. 
Burroughs B6700, B7700 

#9&10: 74-75. 

#11: 81. 

#12: 58-59. 
CDC Cyber 18 and 2550 

#9&10: 75. 

#11: 81-82. 
CDC 3200 

#9&10: 75. 

#11: 82. 
CDC 3300 

#9&10: 75. 
CDC 3600 

#9&10: 75. 
CDC 6000, Cyber 70, Cyber 170 

#9&10: 76. 

#11: 82-83. 
CDC 7600, Cyber 76 

#9&10: 76. 

#11: 83. 
CDC Omega 480 

See IBM 360, 370. 
CDC Star- 100 

#9&10: 77. 
CII Iris 50 

#9&10: 77. 
CII 10070, Iris 80 

#9&10: 77-78. 

#12: 59-60. 
Commodore 6502 

#12: 60. 
Computer Automation LSI-2, LSI-4 

#9&10: 78. 

#12: 60. 
Cray Research Cray-1 

#9&10: 78-79. 
Data General Eclipse 

#9&10: 79-80. 

#11: 85. 

#12: 60-61. 



Data General Nova 

#9&10: 79-82. 

#11: 83-85. 

#12: 60-61. 
DEC PDP-8 

#9&10: 82. 

#11: 85. 
DEC LSI-11 and PDP-11 

#9&10: 82-88. 

#11: 86-91. 

#12: 62-63. 
DEC VAX-1 1/780 

#12: 63. 
DEC DECSystem-10 

#9&10: 89-91. 

#11: 91-92. 
Dietz MINCAL 621 

#9&10: 91-92. 
Foxboro Fox-1 

#9&10: 92. 
Fujitsu FACOM 230 

#9&10: 92. 
Harris / 4 

#9&10: 92-93. 
Heathkit H-11 

#9&10: 93. 
Hewlett Packard HP-2100,21MX 

#9&10: 93. 

#11: 92. 

#12: 63. 
Hewlett Packard HP-3000 

#9&10: 94. 

#12: 63-64. 
Hitachi Hitac 8700, 8800 

#9&10: 94. 
Honeywell H316 

#9&10: 94. 

#11: 93. 
Honeywell 6000 

#96.10: 94-95. 

#11: 92-93. 
IBM Series 1 

#9&10: 95. 
IBM 360, 370 

#9&10: 95-101. 

#11: 93-100. 

#12: 64. 
IBM 1130 

#9&10: 101. 
ICL 1900 

#9&10: 101-102. 

#11: 100-101. 
ICL 2900 

#9&10: 102. 

#11: 100, 101-102. 
Intel 8080, 8080a 

#9&10: 102-103. 

#11: 102. 

#12: 64-66. 
Interdata 7/16 

#9&10: 103. 

#12: 67. 
Interdata 7/32, 8/32 

#9&10: 103-104. 

#12: 67. 



ITEL AS/4, AS/5 

See IBM 360, 370. 
Kardios Duo 70 

#9&10: 104. 
Mitsubishi MELCOM 7700 

#9&10: 104-105. 
MITS Alt air 680b 

See Motorola 6800. 
MITS Alt air 8800 

See DEC LSI-11. 
MOS Technology 6502 

See DEC LSI-11. 
Motorola 6800 

#9&10: 105. 

#11: 102. 
Nanodata QM-1 

#9&10: 105. 
NCR Century 200 

#9&10: 105. 
Norsk Data NORD-10 

#9&10: 106. 
Northwest Micro Systems 85 /P 

#12: 67. 
Prime P-300 

#11: 103. 
Prime P-400 

#9&10: 106. 

#12: 67. 
SEMS T1600, SOLAR 16/05/40/65 

#9&10: 106. 
Siemens 330 

#9&10: 107-108. 
Siemens 4004, 7000 

#9&10: 108. 
Telefunken TR-440 

#9&10: 108. 
Terak 8510 

See DEC LSI-11. 
Texas Instruments TI-ASC 

#9&10: 109. 
Texas Instruments 9900/4 

#9&10: 109. 
Univac 90/30 

#9&10: 109. 
Univac 90/70 

#9&10: 109. 
Univac 1100 

#9&10: 109-112. 

#11: 103. 
Univac V-70 

#9&10: 112. 
Varian V-70 

See Univac V-70. 
Xerox Sigma 6, 9 

#9&10: 112. 
Xerox Sigma 7 

#9&10: 112. 
Zilog Z-80 

#9&10: 112. 

#11: 103. 
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POLICY: PASCAL USER^S GROUP (78/0^/15) 

Purposes: Pascal User's Group (PUG) tries to promote the use of the programming 
language Pascal as well as the ideas behind Pascal. PUG members help 
out by sending information to Pascal News ^ the most important of which 
is about implementations (out of the necessity to spread the use of 
Pascal). 

The increasing availability of Pascal makes it a viable alternative for 
software production and justifies its further use. We all strive to 
make using Pascal a respectable activity. 

Membership: Anyone can join PUG: particularly the Pascal user, teacher, maintainer, 
implementor, distributor, or just plain fan. Memberships from libraries 
are also encouraged. 

See the ALL PURPOSE COUPON for details. 

FACTS ABOUT Pascal, THE PROGRAMMING LANGUAGE: 

Pascal is a smal 1 , practical , and general purpose (but not all-purpose ) 
programming language possessing algorithmic and data structures to aid 
systematic programming. Pascal was intended to be easy to learn and 
read by humans, and efficient to translate by computers. 

Pascal has met these design goals and is being used quite widely and 
successfully for: 

* teaching programming concepts 
developing reliable "production" software Q 



V 



• 



* implementing software efficiently on today's machines 

* writing portable software 



Pascal is a leading language in computer science today and is being %r 
used increasingly in the world's computing industry to save energy and |^ 
resources and increase productivity. ^^ 

Pascal implementations exist for more than 62 different computer systems, 
and the number increases every montti. The Implementation Not^s^ section 
of Pascal News describes how to obtain them. 

The standard reference and tutorial manual for Pascal is: 

Pascal - User Manual and Report (Second, study edition) 
by Kathleen Jensen and Niklaus Wirth 

Springer-Verlag Publishers: New York, Heidelberg, Berlin 
1978 (corrected printing), 167 pages, paperback, $6.90. 

Introductory textbooks about Pascal are described in the Here and There 
Books section of Pascal News . 

The programming language Pascal was named after the mathematician and 
religious fanatic Blaise Pascal (1623-1662). Pascal is not an acronym. 

Pascal User's Group is each individual member's group. We currently have more than 
1923 active members in more than 35 countries. This year Pascal News is 
averaging more than 150 pages per issue. 



Return to: 

University Computer Center 
227 Experimental Engineering Building 
208 Southeast Union Street 
University of Minnesota 
Minneapolis, Minnesota 55455 USA 

return postage guaranteed 
address correction requested 



The University of Minnesota is committed to the policy that all persons shall have equal access 

to its programs, facilities, and employment without regard to race, 
creed, color, age, sex, national origin, or handicap. 



